Detailed Explanation of the MQTT CONNECT Packet and Its Fields
This article provides a comprehensive overview of the MQTT CONNECT packet, covering its fixed and variable header structures, protocol name, level, flags, keep‑alive settings, session handling, will message behavior, payload composition, and the server's validation and response process.
CONNECT
The first packet sent after a client establishes a TCP connection to an MQTT broker must be a CONNECT packet; the client may send it only once, and any subsequent CONNECT must be treated as an error and the connection closed.
Protocol Format
Fixed Header
Variable Header
The variable header consists of four parts: Protocol Name, Protocol Level, Connect Flags, and Keep Alive.
Protocol Name
1. The protocol name is a UTF‑8 string that never changes in future MQTT versions. 2. An incorrect protocol name causes the server to disconnect. 3. Tools can use the protocol name to identify MQTT traffic.
Protocol Level
1. An 8‑bit field indicating the revision; MQTT 3.1.1 uses level 4, MQTT 5 uses level 5. 2. If the server receives an unsupported level, it must return a CONNACK with return code 0x01 and then close the connection.
Connect Flags
The server must verify that reserved bits are zero; otherwise, it must disconnect. The Clean Session flag determines whether an existing session is resumed (0) or a new session is created (1). Detailed behavior for each flag value is described, including session state preservation, will message handling, and QoS message queues.
Will Flag
When set, the broker stores a Will message tied to the network connection; if the connection closes unexpectedly, the Will is published unless the client sends a DISCONNECT first. Conditions for publishing the Will include I/O errors, network failures, missing client communication, abrupt client closure, or protocol errors. Additional notes cover Will QoS, Retain, and deletion after a proper DISCONNECT.
Keep Alive
The Keep Alive value is a 16‑bit field representing seconds (max 18 h 12 min 15 s). It defines the maximum interval between two control packets from the client; if no other packets are pending, the client must send a PINGREQ. The server must disconnect if no packet is received within 1.5 × KeepAlive.
Payload
The payload fields appear in a fixed order determined by the variable header flags: ClientId, Will Topic, Will Message, User Name, Password.
ClientId
Each client must provide a unique UTF‑8 identifier; if the identifier is zero‑length, the server must assign one and require Clean Session = 1, otherwise it returns return code 0x02 and closes the connection.
Will Topic – UTF‑8 string for the Will message topic.
Will Message – Content of the Will.
User Name – UTF‑8 string.
Password – UTF‑8 string; must be zero if User Name flag is zero.
Server Validation and Response
The server must close the connection if it does not receive a CONNECT within the expected time, or if the CONNECT packet violates any specification rule. It may return a CONNACK with an appropriate return code before closing. If a duplicate ClientId is detected, the existing connection is closed. After successful validation, the server sends a CONNACK (fixed header type 2, variable header containing Session Present flag and Return Code) and then proceeds with message delivery and keep‑alive monitoring.
360 Tech Engineering
Official tech channel of 360, building the most professional technology aggregation platform for the brand.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.