As David Barnett points out in his recent blog, the Internet of Things needs many protocols. Two of them, MQTT and DDS, are rapidly becoming the best ways to connect large numbers of devices. The confusion is understandable; the high-level positioning is similar. Both can connect thousands of devices into real-time machine to machine (M2M) networks.
However, they target very different needs.
MQTT targets device data collection. Its name, the Message Queue Telemetry Transport, points this out; the main purpose is telemetry or remote monitoring (see http://en.wikipedia.org/wiki/Telemetry). The goal of MQTT is to collect data from many devices and transport that data to the IT infrastructure. It targets large networks of small devices that need to be monitored or controlled from the cloud. There is little attempt to enable device-to-device transfer, nor to fan out the data to many recipients. Since it has a clear, compelling single application, MQTT is simple, offering few control options. It also doesn’t need to be particularly fast; in this context, real-time is typically measured in seconds.
A hub-and-spoke architecture is natural for MQTT. All the devices connect to a data concentrator server, such as the new IBM MessageSight appliance. You don’t want to lose data, so the protocol works on top of TCP, which provides a simple, reliable stream. Since the data is used by the IT infrastructure, the entire system is designed to easily transport data into enterprise technologies like ActiveMQ and ESBs.
DDS, on the other hand, targets device data use. Its name, the Data Distribution Service, also points out its goal: to distribute data to other devices. While interfacing with the IT infrastructure is supported, DDS exists to connect devices to other devices.
Devices demand data very differently than the IT infrastructure demands data. First, devices are fast; real-time is often measured in microseconds. Devices need to communicate with many other devices in complex ways, so the simple reliable point-to-point streams of TCP are far too restrictive. Instead, DDS offers detailed quality of service control, multicast, configurable reliability, and pervasive redundancy. Fan out is a key factor; DDS offers powerful ways to filter and select exactly which data goes where — which can be thousands of simultaneous destinations. Some devices are small, so there are lightweight versions of DDS that run in constrained environments. But there are also powerful full-featured versions that support large participants in the device network.
Hub-and-spoke is completely inappropriate for device data use. Rather, DDS implements direct device-to-device bus communication with a relational data model. RTI calls this a databus, because it is the networking analog to a database. Similar to the way a database controls access to stored data, a databus controls data access and updates by many simultaneous users. This is just what many high-performance devices need to work together as a single system.
Bottom line: Device data use is a fundamentally different use case from device data collection. Data distribution (DDS) enables devices to use other devices’ data to work together as a coherent system. Data telemetry (MQTT) enables IT infrastructure to monitor and collect data from many devices, thus connecting them to the cloud. There is some overlap: DDS can serve and receive data from the cloud, and MQTT can send information back out to devices. But the fundamental goals differ, the architectures differ, and the capabilities differ. Both protocols are critical to the (rapid) evolution of the Internet of Things.