MQTT Essentials Part 7: Persistent Session and Queuing Messages
Welcome to the seventh part of the MQTT Essentials, a blog series about the core features and concepts in the MQTT protocol. In this post we talk about persistent sessions and message queueing in MQTT. Although MQTT is not a message queue per se, it is possible to queue messages for clients.
When a client connects to a MQTT broker, it needs to create subscriptions for all topics that it is interested in in order to receive messages from the broker. On a reconnect these topics are lost and the client needs to subscribe again. This is the normal behavior with no persistent session. But for constrained clients with limited resources it would be a burden to subscribe again each time they lose the connection. So a persistent session saves all information relevant for the client on the broker. The session is identified by the clientId provided by the client on connection establishment (more details).
So what will be stored in the session?
- Existence of a session, even if there are no subscriptions
- All subscriptions
- All messages in a Quality of Service (QoS) 1 or 2 flow, which are not confirmed by the client
- All new QoS 1 or 2 messages, which the client missed while it was offlne
- All received QoS 2 messages, which are not yet confirmed to the client
That means even if the client is offline all the above will be stored by the broker and are available right after the client reconnects.
How to start/end a persistent session?
A persistent session can be requested by the client on connection establishment with the broker. The client can control, if the broker stores the session using the cleanSession flag (see MQTT Essentials part 3 for more information on the connection establishment between client and broker). If the clean session is set to true then the client does not have a persistent session and all information are lost when the client disconnects for any reason. When clean session is set to false, a persistent session is created and it will be preserved until the client requests a clean session again. If there is already a session available then it is used and queued messages will be delivered to the client if available.
How does the client know if there is already a session stored?
Since MQTT 3.1.1, the CONNACK message from the broker contains the session present flag, which indicates to the client if there is a session available on the broker. For detailed information on the connection establishment see part 3 of the MQTT Essentials.
Persistent session on the client side
Similar to the broker, each MQTT client must store a persistent session too. So when a client requests the server to hold session data, it also has the responsibility to hold some information by itself:
- All messages in a QoS 1 or 2 flow, which are not confirmed by the broker
- All received QoS 2 messages, which are not yet confirmed to the broker
When you should use a persistent session and when a clean session?
A client must get all messages from a certain topic, even if it is offline. The broker should queue the messages for the client and deliver them as soon as the client is online again.
A client has limited resources and the broker should hold its subscription, so the communication can be restored quickly after it got interrupted.
The client should resume all QoS 1 and 2 publish messages after a reconnect.
A client is not subscribing, but only publishing messages to topics. It doesn’t need any session information to be stored on the broker and publishing messages with QoS 1 and 2 should not be retried.
A client should explicitly not get messages for the time it is offline.
How long are messages stored on the broker ?
A often asked question is how long is a session stored on the broker. The easy answer is until the clients comes back online and receives the message. But what happens if a client does not come online for a long time? The constraint for storing messages is often the memory limit of the operating system. There is no standard way on what to do in this scenario. It totally depends on the use case. In HiveMQ we will provide a possibility to manipulate queued message and purge them.
So that’s the end of part seven in our MQTT Essentials series. We hope you enjoyed it. In the next post we’ll cover Retained Messages. If you already tried out MQTT, you surely noticed the retained flag, when sending a message. Next week we’ll cover what Retained Messages are and how they work.
Have a great week and we’ll hope to see you on the next MQTT Monday!
You like the MQTT Essentials? Then sign up for our newsletter and get notified on each new post as soon as its available. If you prefer RSS, you can subscribe to our RSS feed here.