Dot11 Guru

iot, MQTT, scripting

MQTT 3.1.1 – Packets and Expected Application Flows (Publishing Topics)

Building on the previous post introducing MQTT, today we will analyse packets and expected application flows for clients publishing messages through MQTT 3.1.1.

The following image represents a high level overview. We examine each packet in detail below.


Once the network connection has been established to the broker, the first packet must be a “connect” packet. The only mandatory field within the connect packet is the Client ID. Other fields are optional, and their existence made known by setting the relevant flag within the Connect Flags portion of the header.

MQTT 3.1.1 Connect Packet
User NameSet to 0, the username cannot exist in the payload,
Set to 1, the username must exist in the payload
PasswordIf username is set to 0, the password must be set to 0.
Set to 0, the password cannot exist in the payload
Set to 1, the password must exist in the payload
Will RetainIf the will retain is set to 1, and the will flag is set to 0: The broker will publish the will message as a non-retained message.
If the will retain is set to 1, and the will flag is set to 1: The broker will publish the will message as a retained message.
If the will retain is set to 0, the will flag must be set to 0.
(Will) QoS LevelThis specifies the QoS level for publishing the Will
If the will flag is set to 0, the QoS level must be 0.
If the will flag is set to 1, the QoS level can be 0, 1, or 2
Will FlagIf set to 1, and the connection request is accepted, the will must be stored on the server
Clean Session How to handle the session state. If set to 0, the broker must resume communication based on the current session state – or if none, begin a new session. If set to 1 a new session must be created.
ReservedIf not set to 0, the broker must disconnect
Flag Definitions

The keep alive is represented in seconds, and defines the maximum time period permitted between sending of packets.

The payload consists of the following fields which must appear in the order shown below:

Client IdentifierA unique ID to represent the client.
Will TopicThe topic used for the last will and testament, and only exists if the will flag is set to 1
Will MessageThe message to be published to the above will topic. The will is used when a client disconnects in an ungraceful way.
Payload Topics

If the broker receives 2 connect messages from the same client, it is considered a protocol violation, and the client will be disconnected.

Once the broker validates the connect packet, it must return a ConnectAck

Connect ACK

The broker will respond with a Connect ACK. The Connect ACK can contain confirmation that a session exists (depending on the clean session flag within the Connect packet), and a return code.

Connect ACK

The following table illustrates the potential return codes that can be used by the broker.

Return CodeDescription
0Connection Accepted
1The server does not support the version of MQTT used by the client
2Client ID not allowed by the server
3MQTT service is unavailable, the network connection was successful
4Bad username or password
5Client is not authorised to connect
Return Codes


The publish packet is used to transport application data between the client and broker.

Publish Packet

The following fields can be found within a publish packet.

DUP FlagIf set to 1, indicates the message is being resent
QoS LevelThis field can be set to either 0 – at most, delivered once. 1 – at least, delivered once. 2 – Exactly delivered once.
RetainThe message will be retained by the broker and delivered to future subscribers
TopicThe topic of the message
Message IdentifierOnly present if QoS level is set to 1 or 2. The identifier must be the same if the message is being resent. And the acknowledgement to a publish must contain the corresponding message identifier.
MessageThe payload
Publish fields

Publish Ack

The publish ack is sent as a response to a publish packet with QoS Level 1. The message identifier corresponds to the identifier used within the publish packet.

Publish Ack Packet

Publish Rec, Rel and Comp

The Publish Rec packet is the first part of the response to a publish packet using QoS 2. It contains the message identifier corresponding to the publish packet identifier. It is sent from the device receiving the initial publish packet.

The Publish Rel is the second part of the response to a publish packet using QoS 2. It is sent from the same device which sent the publish packet.

The Publish Comp is the final part of the response to a publish packet using QoS 2. and is sent by the device who sent the Publish Rec.

Disconnect Request

The disconnect request is sent by the client to the broker to indicate a clean disconnection. This packet has no payload, and only indicates the packet type through the message type field – Disconnect Req (14)

Disconnection Request packet.

Share this:

Leave a Reply