Persistent Sessions and Message Queuing – MQTT Fundamentals
by Ponlakshmi
Did you know that after a client disconnects, the MQTT broker can store new messages for that client? The messages will be sent as rapidly as the client reconnects. MQTT Persistent sessions & message queuing is the name for this feature in MQTT. In this post, I’ll describe how it performs. Let’s look at this more closely.
MQTT Persistent Sessions or Clean Session
MQTT Persistent sessions as previously stated, the expiry interval specifies how long the session should be kept after a disconnect. Consider the following scenario: Assume you have two MQTT clients that are both connected to a MQTT broker. One MQTT client is publishing to a topic, while the other subscribes it. If the subscribing client disconnects from the broker unexpectedly, it will not receive any messages published to that topic until it reconnects.
When connecting to the broker, we use the Persistent Session or Clean Session flags to solve this problem. When a client connects to the broker, the client has the option of requesting a persistent session. The broker will keep track of the client’s information as well as the topics to which it is subscribed. The broker will transmit all the undelivered messages to the client when the client reconnects after a disconnection.
Setting a clean session
When a client connects to the broker, the client can create a persistent session by setting the cleanSession flag to False. This setting is set to True by default. Let’s take a glance at what a persistent session stores.
- A session’s existence (even without subscriptions).
- The client’s whole subscriptions.
- The client has not yet confirmed all messages in 1 or 2 flow on Quality of Service levels (QoS).
- All new QoS 1 or 2 messages that the client missed while disconnection.
- All QoS 2 messages received from clients are not yet fully accepted.
When should a clean session be used?
When a client needs to receive all (or / and almost all) of the messages from a topic to which it has subscribed and the internet is unreliable, it is essential to use a Persistent Session.
How are client-side actions handled by persistent sessions?
Let’s look at handling client-side persistent sessions. If you want a MQTT persistent session and tell the broker I want a persistent session in the CONNACK packet, there is a small flag called session persistent and the broker tells you as a client if the broker remembers you as a client or if the broker believes you’re connecting for the first time. And this provides you with a convenient way on the client side to determine whether you need to resubscribe to your MQTT topics, or if the broker already has information about you. So this is something to look into, and most libraries allow you to check clean sessions in order to create MQTTclients that are resilient.
Message Queuing
Then there’s message queuing, which is unique to MQTT. Using this messages can be queued per client. Only for persistent session clients, you can use message queuing. If you have an active subscription and a persistent session client that is disconnected from the broker, the broker will queue all quality of service (QoS 1 or 2) messages that you missed while disconnected. This means that if you’re disconnected for a while and then reconnect, the broker will receive messages you missed, so even if you’re connected on the client side, you’ll get the most up-to-date information and won’t miss a message. So this is really great, but you need a persistent session here and you need to use the quality of service one or two messages here. Keep in mind that messages with a quality of service of zero are never queued.
We’ve already discussed persistent sessions and message queuing. It’s possible that if your MQTT broker doesn’t have expire sessions, persistent sessions, or queues, you’re susceptible to denial of service attacks. So, if you’re working on a professional project, make sure you have a MQTT that supports all of the important operations and configurations.
To Learn more about the protocol,
