[6] MQTT, mosquitto, Eclipse Paho --- CONNECT Message format Analysis of MQTT message format, mqttpaho --- mqtt

[6] MQTT, mosquitto, Eclipse Paho --- CONNECT Message format Analysis of MQTT message format, mqttpaho --- mqtt

In "[3] MQTT, mosquitto, Eclipse Paho --- How to Use the Eclipse Paho MQTT tool to send and subscribe to MQTT messages ?" In this article, I have briefly explained how to use Eclipse Paho MQTT. So when we click "Connect", what happened at the TCP protocol layer? How can we compare the Protocol specified by MQTT with the binary data of TCP to learn more about the message format of MQTT? I will take the CONNECT Message format as an example to analyze the first MQTT Message format. The MQTT CONNECT message is mainly used to establish a TCP communication connection between the client and the server, the initiator of this CONNECT must be the client. To establish a connection, the Client must provide the Client ID in the message. If the server has set the user name and password authentication, the information about the user name and password must also be included in the message, in addition, if you have set the Last words (Last Will and Tesament) of the disconnection, the message must contain information related to the Last words.

First, in this instance, the related configuration information for connecting to the MQTT server is as follows. Please remember the following information for establishing an MQTT connection.

At the same time, assuming that everyone has downloaded and installed WireShark (https://www.wireshark.org/download.html) from the address below)

By the way, Wireshark can be divided into capture filter and Display Filer. We only need to input the following filter conditions in the capture filter in WireShark software, TCP data packets that interact with the MQTT service can be captured. As shown in.

At this time, we first start WireShark, and then click "Connect" of the Eclipse Paho MQTT tool. At this time, WireShark can capture the following TCP packets. The specific package is as follows:

Note that the current implementation of the v3.1.1 protocol, please refer to the following documentation
Http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/ OS /mqtt-v3.1.1-os.html#_Toc398718029

(1) fixed head: hexadecimal data:10 1e

Table 1. Fixed Header Format of CONNECT packets

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

 

10 --- indicates the Connect request sent
4e --- indicates that 4*16 + 14 = 78 bytes will be followed. This indicates the remaining 78 bytes, including not only variable headers (10 bytes) but also
Payload)

2. 10 bytes of the variable header

2.1 protocol byte: hexadecimal data: 00 04 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

00 MSB (0)
04 LSB (4)
4d M
51 Q
54 TB
54 TB

2.2 protocol level: hexadecimal data: 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 protocol.

2.3 mark of the connection information, hexadecimal data: ee

Table 4-Connect Flag bits)

Bit	7	6	5	4	3	2	1	0
	User Name Flag	Password Flag	Will Retain	Will QoS		Will Flag	Clean Session	Reserved
Byte 8	X	X	X	X	X	X	X	0

Ee indicates the connection flag, 1110 1110 -- username (1) password (1) Will Retain (1) Will QoS (01), Will (1), Clean session (1) not used (0)

2.4 heartbeat information interval, hexadecimal data: 00 3c

Table 5. Heartbeat interval (Keep Alive)

Bit	7	6	5	4	3	2	1	0
Byte 9	Keep Alive MSB
Byte 10	Keep Alive LSB

 

00 Keep alive Time (MSB): 0
3c represents the low position of the Keep alive Time (LSB): 3*16 + 12 = 60


3 separator: hexadecimal data: 00 1e

4. Client ID: hexadecimal data: 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31

The last 30 bytes indicate clientID (if "Will" is 0, It is not set, and the user name and password are empty, so there Will be no other information in the payload)
111111111111111111111111111111

5. separator: hexadecimal data: 00 3c


6. Will Topic: hexadecimal data: 6c 77 74

The ASCII Code represented by 6c 77 74 is: lwt

7. separator: hexadecimal data: 00 0c

8. Will Message:Hexadecimal data: 48 65 6c 6c 6f 20 57 6f 72 6c 64 21

48 65 6c 6c 6f 20 57 6f 72 6c 64 21 represents the ASCII code as the Last words (Last Will Message: Hello World!

9. separator: 00 05

10. connection Username ):Hexadecimal data: 61 64 6d 69 6e

61 64 6d 69 6e stands for the ASCII code: admin

11. separator: 00 08

12. connection Password:Hexadecimal data: 70 6173 73 77 6f 72 64
70 6173 73 77 6f 72 64 represents the ASCII code as username: password

Congratulations, the entire Connect Message format is analyzed. Don't you feel excited, do you want to try it!

In the next section, we will continue to share with you the ConnAck Message format. This message format is relatively simple and easy. Thank you for your consideration.