MQTT and DDS: Machine to Machine Communication in IoT

The Internet of Things (IoT) has been getting a lot of attention lately. The impetus behind some of this is the recent announcement of an OASIS initiative to standardize the IBM MQTT protocol as a means for “Things” to communicate. This New York Times blog post provides some background on MQTT and the announcement.

If MQTT gives you a sense of déjà vu, then you’re likely familiar with the Object Management Group (OMG) Data Distribution Service for Real-Time Systems (DDS) standard. Like MQTT, DDS was designed specifically to address machine-to-machine (M2M) communication, the foundation for the IoT.

DDS vs. MQTT

However, while they may share common aspirations, MQTT and DDS are very different standards. Each is optimized around different assumptions about how the IoT will be composed:

• MQTT is optimized for centralized data collection and analysis – connecting sensors and mobile devices to applications running in a data center.
• DDS is optimized for distributed processing – directly connecting sensors, devices and applications to each other without any dependence on centralized IT infrastructure.

The differences between MQTT and DDS are manifest in their underlying architectures.

MQTT Architecture

MQTT is hub-and-spoke. Sensors, devices and applications communicate through a message broker running on a server (or appliance) in a data center. All communication routes through this centralized broker.

DDS Architecture

DDS is decentralized. Things that produce data communicate directly with the applications and Things that consume that data. In other words, peer-to-peer. Data only flows to a data center if it’s required in the data center.

Because of their different architectures, MQTT and DDS are suited for different types of applications.

MQTT Applications

MQTT accommodates classic M2M applications, in which a client machine talks to a server machine, one-to-one. An example is remote asset monitoring, such as sensors that monitor oil wells and pipelines.

DDS Applications

DDS is best when not all data processing is centralized. For example, consider a patient monitoring system. Sensor data (such as vital statistics) is needed bedside, at a nurse’s station, for electronic health records and even on a physician’s mobile device. It would be incredibly inefficient to route sensor data through a data center to get it to a co-located bedside monitor. It may even be technically untenable due to the aggregate bandwidth requirement.

Which IoT Communication Protocol is Best?

So, while both MQTT and DDS provide standard communication foundations for the Internet of Things, their architectures lend themselves to very different deployment topologies. Choosing a centralized solution when your data flows are distributed could have a profound impact on your applications’ scalability and efficiency.

Learn more:

Connecting the Pieces: Integrating FACE DDS »

Demonstrating Interoperability Using Connext DDS »

What's New in Connext 6 »