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.
|User Name||Set to 0, the username cannot exist in the payload,|
Set to 1, the username must exist in the payload
|Password||If 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 Retain||If 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 Level||This 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 Flag||If 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.|
|Reserved||If not set to 0, the broker must disconnect|
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 Identifier||A unique ID to represent the client.|
|Will Topic||The topic used for the last will and testament, and only exists if the will flag is set to 1|
|Will Message||The message to be published to the above will topic. The will is used when a client disconnects in an ungraceful way.|
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
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.
The following table illustrates the potential return codes that can be used by the broker.
|1||The server does not support the version of MQTT used by the client|
|2||Client ID not allowed by the server|
|3||MQTT service is unavailable, the network connection was successful|
|4||Bad username or password|
|5||Client is not authorised to connect|
The publish packet is used to transport application data between the client and broker.
The following fields can be found within a publish packet.
|DUP Flag||If set to 1, indicates the message is being resent|
|QoS Level||This field can be set to either 0 – at most, delivered once. 1 – at least, delivered once. 2 – Exactly delivered once.|
|Retain||The message will be retained by the broker and delivered to future subscribers|
|Topic||The topic of the message|
|Message Identifier||Only 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.|
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 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.
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)