Will messaging is MQTT’s ability to gracefully send wills to third parties for devices that may be unexpectedly disconnected. Accidental disconnection includes but is not limited to:

  • The device fails to communicate during the keepalive period due to a network fault or network fluctuation, and the connection is closed by the server
  • The device has an unexpected power failure
  • The server closes the connection when the device attempts to perform an disallowed operation, such as subscribing to a topic that is not within its privileges

A will message can be seen as a simplified version of a PUBLISH message, which also contains topics, Payload, QoS, and other fields. The Will message Will be specified through the CONNECT message when the device is connected to the server, and then when the device is unexpectedly disconnected, the server Will publish the Will message to the Will Topic specified during the connection. This also means that the server must complete the storage of the will message before replying to CONNACK to ensure that the will message can be published in the event of an unexpected disconnection at any later time.

The following is the difference between the will message in MQTT 5.0 and MQTT 3.1&3.1.1:

MQTT 5.0 MQTT 3.1 & 3.1.1
Will Retain Yes Yes
Will QoS Yes Yes
Will Flag Yes Yes
Will Properties Yes No
Will Topic Yes Yes
Will Payload Yes Yes

The functions of Will Retain, Will QoS, Will Topic, and Will Payload are the same as those of ordinary PUBLISH packets.

The only thing worth mentioning is the use scenario for Will Retain, which is a combination of the retention message and the Will message. If the client subscribing to the Will Topic cannot guarantee that the Will message is online when it is published, it is recommended to set Will Retain for the Will message to avoid the subscriber missing the Will message.

Will Flag is usually a field of interest to the MQTT protocol implementer. It is used to identify whether the CONNECT message Will contain fields such as Will Properties and Will Topic.

Finally, the Will Properties field is new to MQTT 5.0. The property itself is a new feature of MQTT 5.0. Different types of messages have different Properties. For example, the CONNECT Packet has attributes such as Session Expiry Interval and Maximum Packet Size. SUBSCRIBE messages have attributes such as the Subscription Identifier.

Attributes such as Message Expiry Interval in Will Properties are basically the same as those used in PUBLISH messages, except for one Will Delay Interval that is unique to the Will Message.

Testamentary delay, as the name suggests, is a delay in publishing testamentary news after the connection has been disconnected. One of its important uses is to avoid sending testamentary messages when the device is briefly disconnected due to network fluctuations, but can be quickly restored to continue providing service, and cause confusion to the subscribers of testamentary messages.

It should be noted that, in addition to the delay interval of the will, the specific delay time for the release of the will message is also limited by the expiration interval of the session, depending on which of the two happens first. So when we set the session expiration interval to 0, that is, the session expires when the network connection is closed, the will message will be published immediately when the network connection is disconnected, regardless of the value of the will delay interval.

Demonstrate the use of will messages

Next we use EMQ X and MQTT X to demonstrate the will message in action.

In order to achieve the effect of the MQTT connection being abnormally disconnected, we need to adjust the EMQ X default ACL rules and related configuration items:

Add the following ACL rules to the etc/acl.conf file to deny the local client from connecting to advertise the test topic. Note that the rule must be added before all default ACL rules to ensure that the rule can take effect successfully:

{deny, {ipaddr, "127.0.0.1"}, publish, ["test"]}.
Copy the code

Then modify the zone.internal. Acl_deny_action configuration item in etc/emqx.conf to disconnect clients when ACL checks are rejected:

zone.internal.acl_deny_action = disconnect
Copy the code

With the above modifications, we start EMQ X.

Next, we create a connection named demo in MQTT X, change Host to localhost, select MQTT Version 5.0 in the Advanced section, The Session Expiry Interval is set to 10 to ensure that the Session does not expire before the will is published.

Set last-will Topic to offline and last-will Payload to offline in the Lass Will and Testament sectionI'm offline, Will Delay Interval (s) is set to 5.

Once the above setup is complete, we click the Connect button in the upper right corner to establish the connection.

Then we create another client connection named Subscriber and subscribe to the Offline topic.

Next, we will return to the demo connection and release a message of any content whose Topic is Test. At this time, the connection will be disconnected. Wait patiently for five seconds and we will see that the subscriber connection has received a will message with the content of I’m offline.

Advanced usage scenarios

Here’s how to use Retained messages in conjunction with Will messages.

  1. Client A will message content is set asoffline, the will subject is set to the same subject as a normal send statusA/status.
  2. When client A connects to the topicA/statusSend the content as follows:onlineAcross messages, other clients subscribe to the topicA/status“, the Retained message isonline.
  3. If client A is disconnected abnormally, the system automatically sends A message to the subjectA/statusSend the content as follows:offlineIs immediately received by other clients that have subscribed to the topicofflineMessage; If the Will message is set to Will Retain, then if there is a new subscription at this timeA/statusThe subject client goes online and will also get the content asofflineWill message.

Copyright: EMQ

Original link: www.emqx.com/zh/blog/use…