Internet of Things Messaging, Part 1: Introducing MQTT

In the world of the Internet of Things one thing you’ve got lots of, apart from things, is messages. When IoT devices generate messages, they send stuff like status reports and environmental measurements; when they receive, they’re being told what to do (“open that valve” or “send your status”) or they’re storing data from other devices or, or ,or … there are endless use cases. Moreover, the number of IoT devices is growing incredibly fast and only their combined message traffic is growing faster. And as well as the explosion of the IoT, there are applications running on smartphones, tablets, and computers that all need the same type of messaging service.

Now there are many ways to handle IoT messaging but one of the most powerful and, for that matter most interesting, technologies are message brokers. Wikipedia explains that a message broker is:

… an intermediary program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. Message brokers are elements in telecommunication or computer networks where software applications communicate by exchanging formally-defined messages. Message brokers are a building block of Message oriented middleware … A message broker is an architectural pattern for message validation, transformation and routing. It mediates communication amongst applications, minimizing the mutual awareness that applications should have of each other in order to be able to exchange messages, effectively implementing decoupling.

Message brokers implement a publish-subscribe (AKA, pub-sub) model where “subscribers” communicate with one or more message brokers to receive messages sent to the broker by “publishers” and, somewhat obviously, a subscriber can also simultaneously be a publisher.

Enough theory! We’re going to look at one of the most popular and effective message broker protocols, MQ Telemetry Transport, or MQTT. Note that the original name is rarely used now and the acronym has evolved into being the protocol’s name. Other historical names for MQTT were “SCADA protocol”, the “MQ Integrator SCADA Device Protocol” (MQIsdp), and  “WebSphere MQTT” (WMQTT).  mqtt.org explains that MQTT is:

… a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise [sic] network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.

In other words, MQTT implementations are excellent choices for endpoint devices such as Raspberry Pis, Arduinos, smart phones OSes, and pretty much any platform that can benefit from simple and low overhead messaging.

The MQTT protocol is, as of writing, at version 3.1.1 and has become an OASIS standard although there are still many implementations in the market that support version 3.1.0 . The latest specification has major improvements over the previous spec and also mandates that MQTT “brokers” should now be called MQTT “servers”. 

IANA has reserved TCP/IP port 1883 for use by MQTT brokers, er … servers, along with port 8883 for MQTT over SSL (note that using SSL introduces an additional communications performance overhead). Many MQTT server implementations also support WebSockets.

The MQTT protocol has five key features:

• Topic-Based Routing. Messages in MQTT implementations are labelled by topic hierarchies such as state/building/room/device/sensor and subscriptions can use wildcards so, for example, all of the sensor data for all laboratories in all buildings in California could be subscribed to as california/+/laboratory/# (+ is a single level wildcard while # matches all following lower levels; we’ll come back to topics later).
• Support for Clean Sessions. When an endpoint connects to an MQTT server for the very first time and new MQTT session is created and both the server and the client note the session by storing data about the state. This saved session state allows the broker to resume message delivery after reconnection so messages that haven’t been sent or received due to disconnection can be delivered. Clean sessions are an option.
• Quality of Service. MQTT’s QoS support allows subscribers and publishers (collectively, “clients”) to select one of three levels of service: 
  • QoS 0, also referred to as “fire and forget”, doesn’t require acknowledgement from a client that have been received. This level potentially sacrifices delivery reliability (messages can be lost) for speed so is more suited for reliable connections. 
  • QoS 1, “at least once” delivery, requires the sender (either the server or client as appropriate) to retry if no acknowledgement is received within the timeout window. On poor quality connections QoS 1 retries can impact performance and duplicate messages are possible.
  • QoS 2, “exactly once” delivery, is like QoS 1 but with a subsequent status exchange to ensure duplicate messages are not delivered. The extra communications has an even higher potential overhead than QoS 1. 
• Retained Messages. When a publisher marks a message in a topic “to be retained” that message is delivered first when an endpoint first subscribes to that topic. Only one retained message is allowed per topic. Consider this to be a “welcome” or “last status” message from a publisher.
• Last Will and Testament Messages. When connecting to a server, a publisher or subscriber can  specify a LWT message for a topic so that if that endpoint disconnects ungracefully, all subscribers to the topic will receive the message. On a graceful disconnection, LWT messages are disposed of.

You might now be wondering, given the recent mega-scale denial of service attack which was delivered by a botnet of 150,000 co-opted IoT devices, what about security? Chapter 5 of the latest standard discusses security but notes that:

This Chapter is provided for guidance only and is Non Normative. However, it is strongly recommended that Server implementations that offer TLS [RFC5246] SHOULD use TCP port 8883 (IANA service name: secure-mqtt).

That said, all serious and useful MQTT implementations include authentication services.

A number of very useful, free, open source MQTT platforms available and in the next part we’re going to focus on one that’s become widely used in IoT systems: Mosquitto.

Comments? Thoughts? Drop me a message or comment below then follow me on Twitter and Facebook. And sign up for my new newsletter!