Let’s look at this scenario:
You have a temperature sensor that publishes the current temperature to a Topic every three hours. So the question arises, if a new subscriber subscribes to this topic right after it has published the current temperature, when will this subscriber receive the temperature message?
That’s right, it has to wait until three hours later when the temperature sensor publishes the message again to receive it. Before that, this new subscriber knows nothing about the sensor’s temperature data.
How can we solve this problem?
This is where the Retained message comes into play to solve this issue. A Retained message is a message with the Retain flag set to 1 in the PUBLISH packet. After the Broker receives such a PUBLISH packet, it will save this message, and when a new subscriber subscribes to the corresponding topic, the Broker will immediately send this message to the subscriber.
Retained Messages
Retained messages have the following characteristics:
-
A Topic can have only one Retained message; publishing a new Retained message will overwrite the old Retained message;
-
If a subscriber uses a wildcard to subscribe to a topic, it will receive all Retained messages on matching topics;
-
Only new subscribers will receive Retained messages; if a subscriber resubscribes to a topic, they will be treated as a new subscriber and will receive the Retained message;
-
When the Retained message is sent to the subscriber, the Retain flag of the message remains 1, allowing the subscriber to determine whether this message is a Retained message for appropriate handling.
Note: Retained messages have no relation to persistent sessions; Retained messages are stored separately by the Broker for each Topic, while persistent sessions are stored separately by the Broker for each Client.
If you want to delete a Retained message, it’s simple; just publish a Retained message with a Payload length of 0 to that topic.
So the solution to the scenario we mentioned at the beginning is straightforward: the temperature sensor publishes the current temperature as a Retained message every 3 hours, so regardless of when a new subscriber subscribes, it can receive the last published data from the temperature sensor.
LWT (Last Will and Testament)
LWT stands for Last Will and Testament, which refers to the will we mention when connecting to the Broker, including the will topic, will QoS, and will message.
As the name suggests, when the Broker detects that a Client has disconnected abnormally, it will publish a message to the will topic. The settings related to the will are specified during the connection establishment in the Variable header and Payload of the CONNECT packet.
-
Will Flag: 1 if using LWT, 0 otherwise
-
Will Topic: The name of the will topic, wildcards cannot be used (set in the Payload of the CONNECT message)
-
Will QoS: The QoS level used when publishing the will message; if the will flag (Will Flag) is set to 0, the will QoS must also be set to 0 (0x00)
-
Will Retain: The Retain flag of the will message
-
Will Message: The content of the will message (set in the Payload of the CONNECT message)
The Broker considers the Client to have disconnected abnormally in the following situations:
-
The Broker detects an underlying I/O exception;
-
The Client fails to interact with the Broker within the Keep Alive interval;
-
The Client does not send a DISCONNECT packet before closing the underlying TCP connection;
-
The Broker closes the connection with the Client due to a protocol error, such as the Client sending a malformed MQTT packet.
If the Client disconnects by publishing a DISCONNECT packet, this is considered a normal disconnection and will not trigger the LWT mechanism. Additionally, the Broker will discard the LWT parameters specified by this Client during the connection.
Based on the properties and triggering mechanisms of the will, it is not difficult to see that will is often used to retrieve the connection status of devices.
Note that simply setting up the will is not enough (because as soon as the subscriber starts, it will receive the will message, and if the publisher is already online at that time, it will lead to inaccuracies), so it is also necessary to actively send a message when the device successfully connects to MQTT, and the topic sent must be the same as the will topic, setting the message’s retain attribute to correct it automatically.