Detailed Explanation of MQTT Persistent Sessions and Clean Session

Author: Zibo Zhou

Original: https://www.emqx.com/en/blog/mqtt-session

Table of Contents

MQTT Persistent Sessions
What Data Needs to be Stored for Persistent Sessions?
Usage of MQTT Clean Session
Session Improvements in MQTT 5.0
Q&A about MQTT Sessions
Conclusion

MQTT Persistent Sessions

Unstable networks and limited hardware resources are two major challenges faced by IoT applications. The connection between MQTT clients and servers may be unexpectedly interrupted due to network fluctuations and resource constraints. To mitigate the impact of network disconnections on communication, the MQTT protocol provides a persistent session feature.

When an MQTT client initiates a connection to the server, it can set whether to create a persistent session. A persistent session retains some important data to allow the session to continue across multiple network connections. The main functions of a persistent session are as follows:

Avoid the extra overhead caused by repeatedly subscribing due to network interruptions.
Avoid missing messages during offline periods.
Ensure that the message quality assurance of QoS 1 and QoS 2 is not affected by network interruptions.

What Data Needs to be Stored for Persistent Sessions?

As mentioned above, persistent sessions need to store some important data to allow the session to be restored. Some of this data is stored on the client side, while some is stored on the server side.

Session data stored on the client side:

QoS 1 and QoS 2 messages that have been sent to the server but have not yet been acknowledged.
QoS 2 messages received from the server but not yet acknowledged.

Session data stored on the server side:

Whether the session exists, even if the rest of the session state is empty.
QoS 1 and QoS 2 messages sent to the client but not yet acknowledged.
QoS 0 messages waiting to be sent to the client (optional), as well as QoS 1 and QoS 2 messages.
QoS 2 messages received from the client but not yet acknowledged, as well as the last will message and the last will delay interval.

Usage of MQTT Clean Session

Clean Session is a flag used to control the lifecycle of the session state. When set to true, it indicates the creation of a new session, which will be automatically destroyed when the client disconnects. When set to false, it indicates the creation of a persistent session, which remains even after the client disconnects, until the session times out and is deregistered.

Note: A persistent session can only be restored if the client reconnects using a fixed Client ID. If the Client ID is dynamic, a new persistent session will be created upon successful connection.

The following is the Dashboard of the open-source MQTT server EMQX. It can be seen that although the connection in the image is in a disconnected state, it can still be viewed because it is a persistent session, and it can be manually cleared in the Dashboard.

Additionally, EMQX also supports setting session-related parameters in the Dashboard.

MQTT 3.1.1 does not specify when persistent sessions should expire. From a protocol perspective, this persistent session should exist indefinitely. However, in practical scenarios, this is not realistic as it would consume significant server resources. Therefore, servers typically do not fully adhere to the protocol and instead provide users with a global configuration to limit the session expiration time.

For example, the free public MQTT server provided by EMQ sets the session expiration time to 5 minutes, a maximum message count of 1000, and does not retain QoS 0 messages.

Next, we will demonstrate the usage of Clean Session using the open-source cross-platform MQTT 5.0 desktop client tool – MQTTX.

After opening MQTTX, it appears as shown below. Click the New Connection button to create an MQTT connection.

Create a connection named MQTT_V3, with Clean Session turned off (i.e., false), and select MQTT version 3.1.1, then click the Connect button in the upper right corner.

The default server for the connection is the free public MQTT server provided by EMQ.

After a successful connection, subscribe to the clean_session_false topic, with QoS set to 1.

After successfully subscribing, click the disconnect button in the upper right corner. Then, create a connection named MQTT_V3_Publish, with the MQTT version also set to 3.1.1. After a successful connection, publish two QoS 1 messages to the clean_session_false topic.

Then select the MQTT_V3 connection and click the connect button to connect to the server, and you will successfully receive the two messages sent during the offline period.

Session Improvements in MQTT 5.0

In MQTT 5.0, Clean Session has been split into Clean Start and Session Expiry Interval. Clean Start is used to specify whether to create a brand new session or attempt to reuse an existing session upon connection, while Session Expiry Interval specifies the expiration time of the session after the network connection is lost.

When Clean Start is set to true, it indicates that any existing sessions must be discarded and a new session must be created; when set to false, it indicates that the session associated with the Client ID must be used to restore communication with the client (unless the session does not exist).

Session Expiry Interval addresses the issue of persistent sessions existing indefinitely in MQTT 3.1.1, which wastes server resources. Setting it to 0 or leaving it unset indicates that the session expires upon disconnection; setting it to a value greater than 0 indicates how many seconds the session will remain after the network connection is closed; setting it to 0xFFFFFFFF indicates that the session will never expire.

Q&A about MQTT Sessions

When a session ends, do retained messages still exist?

MQTT retained messages are not part of the session state and are not deleted when the session ends.

How does the client know if the current session is a restored session?

Since version 3.1.1, the MQTT protocol has designed a Session Present field for the CONNACK message. When the value of this field returned by the server is 1, it indicates that the current connection will reuse the session saved by the server. The client can decide whether to resubscribe after a successful connection based on this field value.

What are the recommendations for using persistent sessions?

Do not use dynamic Client IDs; ensure that the Client ID used for each connection is fixed.
Reasonably assess the session expiration time based on server performance, network conditions, client types, etc. Setting it too long will consume more server resources, while setting it too short may cause sessions to expire before reconnection is successful.
When the client determines that it no longer needs the session, it can reconnect with Clean Session set to true, and disconnect after a successful reconnection. If using MQTT 5.0, it can directly set the Session Expiry Interval to 0 upon disconnection, indicating that the session will expire after the connection is lost.

Conclusion

Thus, we have completed the introduction to MQTT persistent sessions and demonstrated the usage of Clean Session through a desktop client. Readers can refer to this article to implement offline message reception and reduce subscription overhead using MQTT persistent sessions.

Reprint Statement: All reprinted articles must indicate the original source or reprint source (in cases where the reprint source does not indicate the original source). If there is any infringement, please contact for deletion.