Comparison with MQTT

Overview

There has historically been a lot of confusion when discussing how a DXL broker is different from an MQTT broker. The majority of this confusion stems from the fact that the OpenDXL Broker utilizes a highly-modified fork of the popular Mosquitto broker as its core messaging layer.

However, in reality, the goals of DXL and MQTT are quite different.

• MQTT is a standard and the goal of an MQTT-compliant broker (such as Mosquitto) is to implement all aspects of the standard completely across a broad range of platforms.
• The goal for the DXL broker is to create a highly-scalable (see Performance), secure, and optimized broker that requires a minimal footprint (for both on-premise and cloud-based deployments).

In addition to being performant and secure, several other features were required by DXL that are outside of the MQTT specification:

• Multi-tenancy support
• RESTful-like service-based model with load-balancing and failover
• Multi-broker hubs to support failover
• Topic-based routing

It is also worth noting that DXL does not make any modifications to the MQTT protocol itself, and is in fact not MQTT-specific. DXL messages are simply a specific payload format that is recognized by DXL-enabled brokers. In fact, the DXL payload format has been historically tested across a wide variety of other protocols in addition to MQTT.

The following table contains a feature-by-feature comparison between a typical MQTT broker and the OpenDXL broker.

Feature Comparison

Feature	MQTT Broker	OpenDXL Broker
100% standards compliant	yes	no
Full topic wildcarding	yes	no (only supports multi-level, single-level may be added pending performance improvements)
All QOS levels	yes	no (only supports QOS 0, other levels may be added pending performance improvements)
Supports unencrypted connections	yes	no (TLS-based mutual authentication only)
Persistent session support	yes	no
Arbitrary connection identifiers	yes	no (forces identifier to correspond to client certificate's fingerprint)
Multiple connections for same identifier	no	yes (introduces concept of per-client instances)
RESTful-like services	no	yes
Service registry and meta-data	no	yes
Load-balanced services	no	yes
Geographic service affinity (zones)	no	yes
Service failover	no	yes
Multi-broker hubs (failover)	no	yes
Topic-based routing	no	yes
Supports multi-tenancy	no	yes
Message filtering in broker (to specific clients)	no	yes
Message filtering in broker (to specific brokers)	no	yes
Client and CA-based certificate topic authorization	no	yes
Highly performant for large numbers of clients and topics	no	yes (see Performance )