Introduction
Think of a large notice board in a college. It may be distributed in separate sections, like ‘Sports’, ‘Cultural’, ‘Acads’, etc., each section housing relevant announcements. Now the relevant people (profs, student council members, etc.) may post notices in each section, and all the interested students may read it. One student may be interested in more than one section of the bulletin board and may ignore the others. And similarly, one student council member may post notices to multiple sections of the board.
The above ‘notice board’ analogy was used by my professor who first introduced me to MQTT. It does a very good job of explaining the core concepts in MQTT.
Photo by javier trueba on Unsplash
Think of the notice board as a broker, facilitating communication, and the sections of the bulletin board as topics. Think of all relevant people (profs, students, council members) as clients or things, who can subscribe to topics or publish to topics.
How does MQTT work?
MQTT generally works over TCP/IP. However, it can also be supported by any other network protocol that offers lossless, ordered, bi-directional connections. Bi-directional is the key-word here, and one of the major factors favoring MQTT. Its bidirectional nature prevents the need of constant polling to check for new messages.
A client that wishes to connect to a broker sends a CONNECT message, along with a keep-alive time. Once the broker sends an acknowledgment (CONNACK), the connection is established, and it remains established till either one of the following two events happen:
- The client sends a DISCONNECT message
- No message exchange takes place between the client and the broker for 1.5 times the keep-alive period.
Thus, if a client has set a keep-alive time of 30 seconds, and no message exchange happens for 45 seconds, the broker assumes that the client has disappeared (lost internet maybe), and closes the connection. To avoid this situation and keep the connection active, clients can send an empty PINGREQ message at regular intervals.
Properties of an MQTT message
Now that we had an introduction to the core concepts of MQTT and its connection, let’s look at the properties of a message.
Quality of Service (QoS)
This indicates the agreement between the sender and the receiver regarding the delivery guarantee of a message. It can have three values:
QoS 0 (At most once): This is like the fire-and-forget method. The effort is made to transmit a message once. If the receiver receives it, great! If it doesn’t, then no further effort is made to resend it. There is no guarantee of delivery here.
QoS 1 (At least once): This guarantees that the message will be delivered at least once. The sender stores the message till it gets an acknowledgment (PUBACK) from the receiver. The sender can send this message multiple times, in case the PUBACK is delayed. This is more expensive than QoS 0, since here at least 2 messages are exchanged (the actual message, and PUBACK)
QoS 2 (Exactly once): This level guarantees that the message will be delivered exactly once. It is the slowest QoS, and the most expensive one, because it requires at least 4 message exchanges (dual handshake). First, a message is sent to the receiver. The receiver replies with a PUBREC acknowledgment. If the sender doesn’t receive PUBREC, it can resend the message with a duplicate (DUP) flag, so that the receiver realizes that this isn’t a new message. Once the sender receives PUBREC, it can discard the original message and send a PUBREL (release) message to the receiver. Once the receiver receives PUBREL, it can send messages to the subscribers of the topic, and sends a PUBCOMP (complete) acknowledgment to the sender.
Retained Flag
This flag in the message indicates if the broker should retain this message for future subscribers of the topic. A message is usually sent to the current subscribers and then discarded. However, sometimes, critical information (like a configuration change) needs to be sent to not only the current but even future subscribers to a topic. Messages with the retained flag set to true are retained by the broker and sent to any new subscriber to the corresponding topic. Note that brokers allow only one retained message per topic. So if you send a new message with the retained flag to a topic, it will replace any previously retained message.
Why is MQTT preferred for IoT
Several reasons. We already discussed one: bidirectional communication.
Another important reason is scale. Because of the publish-subscribe nature of the communication, you can have one-to-one, many-to-one and one-to-many communication, and this can scale to millions of clients.
Reliability configuration (using QoS) is another feature that allows MQTT adapt to a range of applications. Finally, MQTT is simple to use, and doesn’t have a steep learning curve. Libraries are available in all popular programming languages to help you get started.
Found this post helpful? Then check out other posts on iotespresso.com.