In the "[3] mqtt,mosquitto,eclipse Paho---How do I use the Eclipse Paho MQTT tool to send a subscription to an MQTT message? In this article I've talked to you about how to use Eclipse Paho MQTT. So what happens to the TCP protocol layer when we click on the "Connect" button? How can you learn more about MQTT's message formats by comparing the protocols that are prescribed by MQTT with the binary data of TCP? I will lead you to the Connect message format as an example, analysis of the first MQTT message format, MQTT Connect message is mainly used to establish a TCP communication connection between the client and the server, this connect initiator is definitely the client. Because to establish a connection, so the client in this message needs to provide the customer ID, if the server set the user name and password authentication, in this message must also include the user name and password information, in addition if the connection is set to disconnect the last words tesament), the message must also contain information related to the last words.
First, in this example, the configuration information used to connect to the MQTT server is as follows, so please remember the following information about establishing an MQTT connection.
also assume that everyone has downloaded and installed the Wireshark from the address below ( https://www.wireshark.org/download.html)
By the way, in Wireshark, which is divided into capture filter and display Filer, we only need to enter the following filter conditions in the capture filter in the Wireshark software, TCP-related packets that interact with the MQTT service can be crawled. As indicated.
At this point, we start Wireshark and then click on "Connect" of the Eclipse Paho Mqtt tool, and this time Wireshark can crawl the following TCP packets. The specific packages are as follows:
Note that the v3.1.1 protocol is currently implemented, please refer to the following document
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718029
(1) Fixed head (FIX head): 16 binary data:1e
Table 1. Fixed header format for CONNECT messages
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
BYTE 1 |
MQTT Control Packet Type (1) |
Reserved |
|
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
BYTE 2 ... |
Remaining Length |
---represents the request for Connect sent
4e---indicates that the following will follow 4*16+14=78 bytes, which represents the remaining 78 bytes, including not only the variable head (10 bytes required) Also
68 bytes of load (payload)
2.10 bytes of variable head
2.1 Protocol Bytes: 16 binary data is: 4d 51 54 54
Table 2. Protocol name byte format
|
Description |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Protocol Name |
BYTE 1 |
Length MSB (0) |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
BYTE 2 |
Length LSB (4) |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
BYTE 3 |
M |
0 |
1 |
0 |
0 |
1 |
1 |
0 |
1 |
BYTE 4 |
' Q ' |
0 |
1 |
0 |
1 |
0 |
0 |
0 |
1 |
BYTE 5 |
T |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
0 |
BYTE 6 |
T |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
0
|
MSB (0)
LSB (4)
4d M
Wuyi Q
Si T
Si T
2.2 Protocol Level: 16 binary data is: 04
Table 3. Protocol Version Information table:
|
Description |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Protocol level |
BYTE 7 |
Level (4) |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0
|
04 represents the 3.1.1 agreement.
2.3 Connection information flag bit, 16 binary data is: EE
Table 4-Connection flags bits (connect flag bits)
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
User Name Flag |
Password Flag |
Would Retain |
Would QoS |
Would Flag |
Clean Session |
Reserved |
BYTE 8 |
X |
X |
X |
X |
X |
X |
X |
0
|
EE stands for Connected flag,1110 1110--username (1) password (1) would Retain (1) would QoS ($), would (1), clean session (1) not used (0)
2.4 Heartbeat information interval, 16 binary data: 3c
Table 5. Heartbeat time interval (Keep Alive)
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
BYTE 9 |
Keep Alive MSB |
BYTE 10 |
Keep Alive LSB |
Keep alive Time of the High (MSB): 0
3c stands for Keep Alive Time Low (LSB): 3*16+12=60
3 Separator flag: 16 binary data:1e
4. Client ID: 16 The binary data is:------- - -----
The next 30 bytes represent ClientID (if will is 0, there is no setting, and the user name and password are also empty, so there is no additional information in the back payload)
111111111111111111111111111111
5. Separator flag: 16 binary data:3c
6. The would topic:16 binary data is: 6c 77 74
the ASCII code represented by the 6c 77 74 is: LWT
7. Separator flag: 16 binary data: 0c
8. Would Message: 16 binary data: 6c 6c 6f + 6f 6c
6c 6c 6f 64 6f + 6c 21 represents the ASCII code is the last words (Message:hello world!
9. Separating Mark: 00 05
10. Connected user name (Username): 16 binary data: 6d 6e
6d 6e represents the ASCII code is the user name: admin
11. Separating Mark: 00 08
12. Connection Password Password: 16 binary data: 6173 6f
6173 6f 72 64 represents the ASCII code is the user name: password
Congratulations, the entire Connect message format has been analyzed. According to the excited mood of you, is not tempted!
Next chapter, we will continue to share the Connack message format, this message format is relatively simple and easy, please look forward to, thank you.
[6] mqtt,mosquitto,eclipse Paho---MQTT message format for connect message format analysis