I’ve been reading about a common communication protocol in IoT called MQTT, and I just wanted to summarize some things I’ve learned recently.
It’s commonly used in IoT because it’s lightweight and it was designed for devices with limited resources or networks with limited bandwith. This is greate for IoT since it allows quick, real time message passing and many to many communications.
MQTT also has Quality of Service built into it unlike HTTP that requires the application layer to take care reliability of message delivery. This is handy for situations where a device might be located in a space with poor connectivity (Think agriculture applications).
Protocol Architecture
Something about MQTT that I thought was pretty nifty was the Publish-Subscribe model. Unlike HTTP which is based on a client server message relationship, there’s a “middle man” between communicating clients call the broker.
It’s like two kids that have a crush on each other but are too shy to talk directly, so they have a a friend do all the note passing for them.
The two clients talking to each other can either be a publisher (sending messages) or a subscriber (reciving messages). This decoupling of the publisher and the subscriber means that they don’t have to know about each other. Because of this, the scalability
of the application becomes simplifed. This is beneficial for systems that are connected to many devices, as messages are in a queue to be recieved rather than waiting on a specific server to be available. Moreover, because the broker is mediating message passing, messaging can now be asyncronous. This is good news for devices with intermittent connectivity.
Even if the connection to the device is lost, the device is able to send the message to the broker when the connection has been reestablished.
Here’s a graphic of MQTT in action that I took from the Wikipedia page for MQTT:
The image above reads from the top to the bottom (starting with connect). You can see that clients can act as both Subscribers and Publishers in this architecture.
Quality of Service (QoS) Levels
I mentioned above that Quality of Service (QoS) is built into MQTT. There three levels that define the reliability of message exchanges between clients and the broker. The publishers and subscribers can each define their level of QoS depending on the client’s application. The three levels of QoS are:
-
QoS 0 (At most once)
QoS zero known as “fire and forget,” this is the lowest level of assurance. Messages are delivered at most once, the publisher will not recieve any confirmation that the message was recieved and the publisher won’t have any menchanisms to retry sending.
-
QoS 1 (At least once)
QoS 1 ensures that messages are delivered at least once. This level may result in duplicate messages sent by the sender. The sender will resuend the message within a timeout sessions unless the sender receives an acknowledgment (PUBACK) from the recipient.
-
QoS 2 (Exactly once)
This is the highest level of assurance, and messages are delivered exactly once. It involves a four-step handshake process between the publisher, broker, and subscriber. Once the message has been published by the sender and delivered to the broker, the broker will store the message until the sender recieves an acknowledgment (PUBREC) from the broker. Once the sender receives the PUBREC, the sender will send a PUBREL confirmation to the broker. The broker will then send the message to any subscribers. The subscriber acknowledges recieving message by sending a PUBCOMP to the broker. The broker will then concider the message recieved.
Last Will and Testament (LWT)
The last topic I want to summarize is the Last Will and Testament (LWT) feature. LWT allows clients to specify a message that the broker will publish in case the client has an unexpected disconnection. This feature us useful for notifying other devices in the system that the client is disconnected.