Persistence Session & Message Queueing in MQTT

What is Persistent Session & Message Queueing?

Persistent Session

We have seen MQTT connect packets can carry a clean session flag and if you set this to false which means you have a persistent session.

You’re basically telling the broker that you want to have a session which the broker remembers and one of the key design principles of MQTT is that it’s easy to implement on the client side and so all the complexity is pushed to the broker.

So, what is great here, if you want of a persistent session the broker remembers the client. So, if you go offline for any reason the broker remembers your state and you can continue your state as soon as a reconnect as a MQTT client. you can enable this feature basically by connecting with clean session equals false in the connect packet and all MQTT libraries of course support this behavior.

You can also have a clean session. A clean session basically means that you tell the broker that you don’t want to be remembered and the broker deletes all state the client has as soon as the client disconnects.

But, what data is persisted actually on the broker? what data does the broker remember?

1. Session data
2. Subscriptions
3. Quality or service messages
4. Queued messages

How can we resume?

We can resume by using the connect packet. If you want to have a MQTT persistent session and you tell the broker i want a persistent session. In the connack packet there is a tiny flag called session present and the broker tells you as a client if the broker remembers you as a client or if the broker is under the impression that you have connected for the first time and this gives you a neat way on the client side to understand if you need. for example, re-subscribe to your MQTT topics or if the broker already has information about you so this is something this is cool to check and most libraries allow you to check this to build resilient MQTT clients.

Message Queueing

Message queueing and messaging is something that is very unique to MQTT because messages are queued per client. If you you have a persistent session client which is offline and you have active subscriptions the broker will queue all quality of servers one or two messages for you which you missed while you were offline, this means if you’re offline for a while and you go online again the broker will redeliver messages you missed and so even if they have a connection hiccup on the client side you get the freshest information and you don’t miss a message.

So, this is really great but you need a persistent session here and you need to utilize the quality of service one or two messages. Here, remember quality of service zero messages are never queued.

When do you want to use a clean session?

If you have a client where it’s absolutely okay. If you miss messages or you have a client which will probably never come back.

When to use a persistent session?

When you have a subscriber which cannot miss messages and you really want to have state and the broker should queue for you then you want to have a persistent session.

Also Read: Features of MQTT