MQTT Operation
In an MQTT protocol, there is a broker which acts as a server and clients are sitting at both ends. The act of sending data to the broker is called publish. Like a variable in a C Program, the data is identified by a namespace. For example, to store a temperature sensor data from room 1, you can use a namespace “room1/temp”.So first let’s understand how MQTT works.
In this protocol, first, the data gets published to the broker and is stored there. If another client needs this data, they need to particularly request to receive updates, this is called “subscribe”. The subscribed clients get the data when that particular topic gets updated. Broker publishes the data from the topic to the publisher whenever it receives it.
The topic acts as a virtual channel that is managed by a broker to connect clients at both ends. It can also use to create filters and create interesting topic levels. For example, building1/room1/temp, building1/room2/temp etc.
The hierarchical topic levels are useful in subscribing and filtering using wildcards. For example, subscribe to all room temperatures, one can subscribe to building1/+/temp. To subscribe all the data from building1, we can subscribe to building1/#
MQTT Features
Quality of Service
MQTT has three QoS level 0,1,2, each level defines service level quality. The overhead increases by increasing each level.
- QoS = 0
Delivery at most once: The delivery will be tried once based on the network conditions. The receivers will not acknowledge the delivery. The receiver may get the message or may not. This is the fastest method out of all three.
- QoS = 1
Delivery at least once: By specifying this QoS level, the message will be delivered at the receiver surely once. There is a chance to get duplicate messages if the acknowledgment is received at the broker.
Steps followed in QOS level 1 is as follows :- The client sends a message and waits for the acknowledgment – PUBACK
- If it receives an acknowledgement then it notifies the client app and deletes the message from the queue.
- If it doesn’t receive an acknowledgement it will resend the message with the Duplicate flag set.
- QoS = 2
Exact one delivery: At this level, there are no duplicate messages. Just one delivery ensured and no more. This is also the safest and slowest method out of all three.
Steps followed in in QOS level 2 is as follows :- The sender sends a message and waits for an acknowledgment – PUBREC
- If the sender doesn’t receive a PUBREC response it will resend the message with the Duplicate flag set.
- Else if the sender receives a PUBREC response it will send back a release message (PUBREL).
- If the receiver is not receiving any PUBREL response. it will again send the PUBREC message.
- But if the receiver received the PUBREL message, it can now forward the message onto any subscribers and then send a publish complete (PUBCOMP) response to the sender.
- If the sender doesn’t receive the PUBCOMP message it will resend the PUBREL message.
- But if the sender received the PUBCOMP, the process is complete and it can delete the message from the queue.
If subscribers reconnect to a broker, they will get the messages marked as QoS level 1 and 2.
Last will Testament
Last will testament is a feature of MQTT which can be used to deliver a message to the subscribers when the publisher gets disconnected. The basic process involved in this is :
- The publisher asks the broker to notify all subscribers to a topic, using the last will message, when the connection breaks.
- If the broker detects a connection break it sends the last will message to all subscribers of that topic behalf of the publisher since the publisher cant publish anymore.
Keep-Alive
Keep-alive is the maximum time interval in seconds, allowed between two messages sent from the client. Or it is the maximum length of time the client and broker stays connected without any communication. This duration is defined by the client when it establishes a connection with the broker. And it is the responsibility of the client to make sure the intervals between each message is less than the keep-alive value.
If the client does not have any messages to send between this interval, it has to send a PINGREQ packet within the interval of one and a half times the Keep alive value. And as a response the broker will send a PINGRESP packet This is done to make sure the broker is still available and confirm the broker, the client is also available. If this fails then the server considers the connection broken and closes it.
Persistent session
For communication between publisher and subscriber, The subscriber has to connect to the broker and create a subscription to the topic it is interested in. If the connection between the subscriber and broker is interrupted during non-Persistent session these topics are lost and subscriber needs to subscribe again on reconnect.
Re-subscribing repeatedly when the connection is interrupted can be a burden and to avoid this subscriber can request a persistent session when it connects with the broker. persistent sessions save all information that is relevant for the client on the broker even when the client goes offline.
in a persistent session broker stores the following information :
[fusion_global id=”18383″]
Retained messages
when MQTT client subscribes to a topic on a broker it won’t receive any of the messages published on it before subscription. But if a client publishes a message to a topic with the retain flag set to True then the broker will save that corresponding message as last retained message. And this message will be received by any client as soon as they subscribe to that topic.
You can see all the packets transmitted or received for each of these different options using a network analyzer.
You can download free and opensource network analyzer called Wireshark from: https://www.wireshark.org/
As an MQTT client, you can use the software; MQTTfx: https://mqttfx.jensd.de/