Overview: The MQTT Protocol
This is an overview of the Message Queuing Telemetry Transport (MQTT) protocol, a critical component of any successful IoT project. MQTT’s v3.1.1 specification is quite complex, and describes the messages, topics, and underlying functionality of the MQTT protocol.
Fortunately, there are a variety of SDKs (sometimes called clients) that manage the complexity of the protocol for developers so they can focus on the important aspects of their projects rather than the implementation of the protocol.
For IoT projects, here are the key MQTT concepts that are important to understand (click to jump to any selection):
- Publishing and subscribing
- QoS levels
- Session management
- Retained messages
- Last will
Topics are the main subject construct for MQTT. A topic is the pipe or channel that messages are sent down. When sending a message, you send it down a specific topic. Two key concepts to understand here are “topic names” and “topic filters.”
Topic names, which are used for sending messages, are UTF-8 strings that are composed of topic levels separated by a forward slash ‘/’ character and are therefore hierarchical in nature.
Note: Topic names are case-sensitive, and while spaces in the names are technically allowed, best practices suggest not using them.
While topic names are used for sending messages, topic filters are used for listening to messages. A topic filter is a topic with one or more wildcard characters. A ‘+’ character can be used to wildcard a topic level, while a ‘#’ character can be used to wildcard multiple topic levels and must only be used at the end of topic filter. So, by subscribing to room/ma/cambridge/+/150/9/114, the device would receive (or “listen to”) all messages for all device types in that room — there’s no need to individually subscribe to every device type, or even know what they are, to receive all of the messages. Likewise, subscribing to room/ma/cambridge/thermostat/# the subscriber will receive all messages from all thermostats everywhere.
Publishing and Subscribing
Publishing and subscribing to topics provides the basic functionality of MQTT. In a traditional pattern, a producer (or device) would send messages directly to all of the consumers. This required the producers and consumers to be aware of each other, understand the security rules for communications, and to be connected directly with each other.
With MQTT, the producer and the consumers are decoupled. Instead of sending messages directly to the consumers, the producer publishes messages to a specific topic directly to the broker. The consumers subscribe to either a specific topic or a group of topics, called filters, and the broker sends the consumers the messages. The broker acts as a middleman for all communication, and it understands (via rules set by the developer) who can publish and who can subscribe to various topics.
A topic is the name of the channel that messages can be delivered upon. Topics are hierarchical in nature and have various segments, called levels. When publishing, the producer needs to specify the exact topic that the message will be delivered upon. When subscribing, however, the consumer can subscribe to a topic filter. A topic filter looks like a topic, but some of the levels can be replaced with a wildcard. The ‘+’ wildcard specifies one level, while the ‘#’ specifies multiple levels. The ‘#’ wildcard must appear at the end of the topic filter.
For example, room/ma/cambridge/thermostat/150/9/114 describes a thermostat on the 9th floor in room 114 of an office building at 150 Broadway in Cambridge. The thermostat setting can be set by publishing a message to the specific topic. Subscribing to room/ma/cambridge/thermostat/150/# topic filter (the ‘#’ wildcard here specifies multiple levels) would provide a mechanism for listening to all messages going to all thermostats in that building. Likewise, subscribing to room/ma/cambridge/+/150/9/114 topic filter (the ‘+’ wildcard here specifies one level) provides a mechanism for listening to all of the devices in room 114.
When publishing and subscribing, the client must specify what level of delivery and cross-session guarantee the message has. This is called quality of service (QoS) and there are three levels: 0, 1, or 2.
- QoS 0 messages are sent at most one time; they are not guaranteed to be delivered and are not resent. They are also the fastest. They can be used to send regular information, where if one or two messages are not received, it isn’t a problem. A thermostat sending the current room reading is a good use: if one message among a series of messages sent every 30 seconds gets lost, it isn’t a problem.
- QoS 1 messages are sent at least once. If the recipient doesn’t send an acknowledgment (or “ACK”) back within a certain amount of time, it is resent. QoS 1 is more reliable but not as fast as QoS 0, and is ideal for command-and-control messages, like setting the temperature of the thermostat.
- QoS 2 messages are delivered to the device exactly once. Use a QoS 2 message if you want to make sure that only one copy of the message will be delivered to the application. A good example would be adding 1,000 coins to a game console.
Sessions are a significant part of the MQTT specification; they provide a mechanism to allow a device to connect, subscribe, disconnect, and still receive messages that are published when the device is offline. These sessions capabilities remove the burden of guaranteed message delivery—and of retransmits—from developers. When the device connects, it can specify whether it wants to reconnect; reconnecting to a session will then allow the device to get whatever messages it missed.
Each topic can have a message that is associated with it called a retained message. A retained message is attached to the topic until it is cleared. When a device subscribes to a topic containing the retained message, that message is delivered regardless of when the device subscribed to the message.
The last will message can be set when a device connects. It tells the broker that if the device should abruptly drop the connection without sending the DISCONNECT message, it should send the specified message down the specified topic at the specified QoS level. The last will message also provides a way to determine the device’s presence.
The MQTT protocol is powerful and complex, and is an important element of successful IoT projects. The information above is designed to provide you with a basic understanding of how your IoT devices can optimally participate in an MQTT ecosystem.
To give MQTT a try, get started with Akamai Edge Connect.