Fundamentals 11 min read

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.

360 Tech Engineering
360 Tech Engineering
360 Tech Engineering
Detailed Explanation of the MQTT CONNECT Packet and Its Fields

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.

messagingIoTprotocolFundamentalsCONNECTMQTT
360 Tech Engineering
Written by

360 Tech Engineering

Official tech channel of 360, building the most professional technology aggregation platform for the brand.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.