persistent session
when a client connects to MQTT broker, it needs to subscribe to all topics it is interested in in order to receive messages from broker. When you reconnect, the subscribed topics are lost and the client needs to restart the subscription. This is a normal process when there is no persistent session. However, for devices with limited resources, it will be a heavy burden to re-subscribe every time you reconnect. Therefore, the persistent session saves all the information about this client on the broker to solve this problem. The session is determined by the clientId provided by the client when establishing the connection.
what information will be stored in the session?

even if there is no subscription, a session is generated
all subscription information
all messages that have not been acknowledged by the client and have QoS levels 1 and 2
all messages that have not been received because the client is offline and QoS levels 1 and 2
all clients have received messages with QoS 2 that have not yet been acknowledged

this means that even if the client is offline, all of the above information will be stored by broker and continue to be used the next time the client reconnects.
how to start / close persistent sessions
persistent sessions can be requested when a client establishes a connection with broker. The client can use the cleanSession flag to control whether the broker needs to save the session (see the client and broker connection section in part 3). If cleanSession is set to true, there will be no persistent session on the client and all messages will be discarded in any case when the connection is disconnected. When cleanSession is set to false, persistent sessions will be created until the client sets cleanSession to true again. If a persistent session is available, the message is delivered to the available client in the form of a queue.
how does the client know if the session is stored?
starting with MQTT 3.1.1, the CONNACK message sent by borker contains the current session flag, which indicates to the client whether the current session is available. For more details, see the establish connection section in Part 3
persistent sessions on clients
similarly, each MQTT client must store a persistent session. So when the client asks the server to store session data, the client itself has the responsibility to keep some information:

all messages with QoS of 1 and 2 have not been acknowledged by broker
all received messages with QoS of 2 that have not been confirmed by broker

Best practices
when should you use and clear persistent sessions?
persistent session

the client must receive all messages for a topic, even if it is offline. Broker needs to sort the messages and send them to the client when it connects.
the client has only limited resources and broker needs to control subscriptions and needs to recover quickly when communication is interrupted. The
client needs to continue publishing messages at QoS 1 and 2 levels after reconnecting.

clear the session

the client only publishes but does not subscribe to topic messages, and messages with QoS levels 1 and 2 do not need to be retransmitted after reconnection. In this case, it does not need to store any session information on the broker.
the client does not need to receive messages when offline.

how long should messages be stored on broker?
A frequently asked question is how long a session should be stored on broker. A simple answer is that it should be stored when the client comes back online. But what if the client is no longer online for a long time? After all, the operating system's memory is limited. There is no definite solution to this. It all depends on the usage scenario. In HiveMQ, we provide a way to manipulate message queues and empty them.

author: qinwenbo
Link: https://www.jianshu.com/p/379...
Source: brief Book
the copyright of the simplified book belongs to the author. For any form of reprint, please contact the author for authorization and indicate the source.