Welcome to the fifth article in the MQTT 5.0 message series. In the previous article, we introduced the MQTT 5.0 PINGREQ and PINGRESP messages. Now, we will introduce the next control message: DISCONNECT.
In MQTT, the client and server can send a DISCONNECT message to the other party before disconnecting the network, indicating the reason for the connection closing. The DISCONNECT message sent by the client can also affect the server’s behavior after the connection is closed, such as whether to send a will message or update the session expiry interval.
Example of a DISCONNECT Message in MQTT 5.0
We use MQTTX CLI to initiate a client connection with a specified Client ID to a public MQTT server and set --reconnect-period to 0 to disable automatic reconnection, then run the same command in another terminal to create a connection using the same Client ID.
The entire process utilizes the Wireshark tool to capture MQTT messages round-tripping between the client and server. In a Linux environment, you can use the tcpdump command to capture the packets and then import them into Wireshark for analysis.
The following command will create a client connection with Client ID mqtt-892324. To avoid duplication with others, it is recommended to change it to another random string:
Code language: mqttCopy
mqttx conn --hostname broker.emqx.io --mqtt-version 5 --client-id mqtt-892324 \ --reconnect-period 0After we initiate the second connection, Wireshark will capture the DISCONNECT message returned by the public MQTT server to the first connection:
Code language: mqttCopy
e0 02 8e 00These four hexadecimal bytes correspond to the following message content:
Through the introduction of the DISCONNECT message structure below, you will learn how to extract the information you need from the raw message data.
MQTT 5.0 DISCONNECT Message Structure
Fixed Header
The high 4 bits of the first byte of the fixed header, which is the value of the message type field, is 14 (0b1110), and the lower 4 bits are all 0, indicating that this is a DISCONNECT message.
Variable Header
The variable header of the DISCONNECT message contains the following fields in order:
- Reason Code: A single-byte unsigned integer used to indicate the reason for the connection disconnection to the other party. The following table lists common Reason Codes in DISCONNECT messages, with a complete list available in the MQTT 5.0 Reason Code Quick Reference.
|
Value |
Reason Code Name |
Sent By |
Description |
|---|---|---|---|
|
0x00 |
Normal disconnection |
Client, Server |
Indicates normal closure of the connection, so the server will not publish a will message. |
|
0x04 |
Disconnect with Will Message |
Client |
Connection closes normally, but the client wants the server to still publish the will message. |
|
0x81 |
Malformed Packet |
Client, Server |
Indicates a control packet that cannot be correctly parsed according to the protocol specification, referred to as a malformed packet in MQTT. |
|
0x82 |
Protocol Error |
Client, Server |
Protocol errors usually refer to errors found after a control packet is parsed according to the protocol specification, including containing data not allowed by the protocol, behavior that does not conform to protocol requirements, etc. For example, a client sends two CONNECT messages in one connection. |
|
0x8D |
Keep Alive timeout |
Server |
The server did not receive any packets within 1.5 times the Keep Alive period, so it closed the connection. |
|
0x8E |
Session taken over |
Server |
Another updated connection using the same Client ID was established, causing the server to close this connection. |
|
0x93 |
Receive Maximum exceeded |
Client, Server |
Indicates that the number of QoS > 0 PUBLISH messages sent simultaneously by the other party exceeds the maximum set when the connection was established. |
|
0x94 |
Topic Alias invalid |
Client, Server |
Indicates that the topic alias is invalid. For example, the topic alias value in the PUBLISH message is 0 or greater than the maximum topic alias agreed upon during connection establishment. |
|
0x95 |
Packet too large |
Client, Server |
Indicates that the packet exceeds the maximum allowed length agreed upon during the connection. |
|
0x98 |
Administrative action |
Client, Server |
Indicates that the connection was closed due to an administrative action, such as the administrator kicking out the client connection from the server background. |
|
0x9C |
Use another server |
Server |
Indicates that the client should temporarily switch to another server. If the other server is not known to the client, it needs to be used in conjunction with the Server Reference property to inform the client of the new server’s address. |
|
0x9D |
Server moved |
Server |
Indicates that the client should permanently switch to another server. If the other server is not known to the client, it needs to be used in conjunction with the Server Reference property to inform the client of the new server’s address. |
- Properties: The table below lists all available properties of the DISCONNECT message.
|
Identifier |
Property Name |
Sent By |
Type |
|---|---|---|---|
|
0x11 |
Session Expiry Interval |
Client |
Four-byte Integer |
|
0x1F |
Reason String |
Client, Server |
UTF-8 Encoded String |
|
0x26 |
User Property |
Client, Server |
UTF-8 String Pair |
|
0x1C |
Server Reference |
Server |
UTF-8 Encoded String |
Unlike other messages introduced previously, the Reason Codes and properties that can be used by clients and servers in DISCONNECT messages are different. For example, the Session Expiry Interval property can only be used in DISCONNECT messages sent by clients, so we have listed their available scope in the list above.
Payload
DISCONNECT messages do not contain a payload.
Summary
Both clients and servers can send DISCONNECT messages, indicating preparation to disconnect the network connection. The Reason Code in the message can indicate the reason for connection closure to the receiver. When an MQTT connection is unexpectedly disconnected, we should first check whether a DISCONNECT message has been received and the value of the Reason Code in the message.
Although there are differences in the Reason Codes and properties that clients and servers can use in DISCONNECT messages, there is no need to forcefully memorize them. They are usually related to the corresponding mechanism and behavior. For example, will messages are only published by the server, so the Reason Code 0x04, which indicates that the connection should close normally but the other party should still publish the will message, is also used by the client.
That’s the introduction to the DISCONNECT message. In the next article, we will introduce the AUTH message used in the enhanced authentication feature of MQTT 5.0, which is also the last message type in MQTT.
Original declaration: This article is authorized by the author to be published in the Tencent Cloud Developer Community. Unauthorized reproduction is not allowed.
If there is any infringement, please contact [email protected] for deletion.
“`