MQTTv5 CONNECT and CONNACK Messages -Overview

The MQTT CONNECT and response messages (CONNACK) have been greatly enhanced in MQTTv5 with the addition of the properties field.

The properties field allows for a large increase in the information that can be exchanged between client and server on connection establishment compared to MQTT v3.1.1.

For example it is now possible to restrict the maximum message size the server will send to the client by telling the server what message size the client will accept.

It is also possible to learn what restrictions the broker imposes on the client by examining the Connection acknowledgement message.

The purpose of this tutorial is to provide an overview of the CONNECT message in MQTTv5 and do a quick Comparison with MQTT v3.11.

The Connect Packet v3.1.1 and v5

The table below shows the differences between CONNECT messages in version MQTT 3.11 and MQTT v5:

Information Sent in The Connect Packet
MQTTv3.11	MQTTv5
Control Packet Type	Control Packet Type
Protocol Name and Version	Protocol Name and Version
Connect Flags	Connect Flags
Keep Alive	Keep Alive
	Properties
Connect Payload	Connect Payload

As you can see in the table above the messages are more or less identical with the exception of the properties field.

This field has been added to various messages including the CONNECT and CONNACK messages as well as the DISCONNECT and other messages.

The properties object varies according to the message type as detailed in the property fields by message type tutorial.

Connect Message (CONNECT)

This consists of three parts:

• Fixed Header
• Variable Header
• Payload

Fixed Header

This is two to four bytes. The first byte contains the Message Control Packet Type (CONNECT) and a remaining length field.

The remaining length field is encoded as a variable byte integer and can vary between 2 and 4 bytes.

Variable Header

The CONNECT variable header contains the following fields listed in order

• Protocol Name and Version – 1 Byte
• Connect Flags -1 Byte
• Keep Alive duration – 2 Bytes
• Properties – Variable bytes

Connect Flags

The one byte connect flags field is 1 byte with the bits representing flags. There is only one change to the flags. The flags are:

Clean Start
Will Flag
Will QoS
Will Retain -New in MQTTv5
User Name Flag
Password Flag
Keep Alive

 

 Connect Properties

This field is new to MQTTv5 and is of variable length. Each property has an identifier and one more bytes.

For example the identifier for the Session expiry Interval is 0x11 and had 4 bytes for the interval in seconds.

A list is below the links are to the MQTTv5 specification that describe the field.

• 3.1.2.11.2 Session Expiry Interval
• 3.1.2.11.3 Receive Maximum
• 3.1.2.11.4 Maximum Packet Size
• 3.1.2.11.5 Topic Alias Maximum
• 3.1.2.11.6 Request Response Information
• 3.1.2.11.7 Request Problem Information
• 3.1.2.11.8 User Property
• 3.1.2.11.9 Authentication Method
• 3.1.2.11.10 Authentication Data

Connect Payload

This is the same as MQTTv3.1.1. The Connect message includes the client Id, will properties, topic and payload as well as username and password as part of the Payload.

The presence of these fields is indicated by flags in the variable header If present they must appear in the correct order.

However the Will message properties have been expanded considerably and are listed below. I will be creating a separate tutorial to cover this.

Will Properties

Will Property length
Will Delay Interval
Payload Format Indicator
Message Expiry Interval
Content Type
Response Topic
Correlation Data
User Property

Will Topic
Will Payload
User Name
Password

CONNACK– Connection Acknowledge

The two main changes to the CONNACK message between MQTTv3.1.1 and MQTTv5 are the enhanced reason codes and the properties field.

Connect Reason Code

This field is new to MQTTv5 and is a 1 Byte field with values above 128 decimal indicating a failure and a value of 0 is a success.

A full list is contained in the specification but examples are:

Packet too large value=149
Client Identifier not valid value=133
Bad username or password value=134

Properties Field

This field is new to MQTTv5 and is of variable length. Each property has an identifier and one more bytes.

A list is below which will give you a good idea of what type of information can be sent to the client from the server. The links are to the MQTTv5 specification that describe the field..

• 3.2.2.3.2 Session Expiry Interval
• 3.2.2.3.3 Receive Maximum
• 3.2.2.3.4 Maximum QoS
• 3.2.2.3.5 Retain Available
• 3.2.2.3.6 Maximum Packet Size
• 3.2.2.3.7 Assigned Client Identifier
• 3.2.2.3.8 Topic Alias Maximum
• 3.2.2.3.9 Reason String
• 3.2.2.3.10 User Property
• 3.2.2.3.11 Wildcard Subscription Available
• 3.2.2.3.12 Subscription Identifiers Available
• 3.2.2.3.13 Shared Subscription Available
• 3.2.2.3.14 Server Keep Alive
• 3.2.2.3.15 Response Information
• 3.2.2.3.16 Server Reference
• 3.2.2.3.17 Authentication Method
• 3.2.2.3.18 Authentication Data

Important CONNACK Properties

The server can now provide capability information to the client in the CONNACK message as well as reason codes useful in failed connections.

Examples:

Maximum QOS -Maximum QOS that the server will accept
Maximum Packet Size – Maximum packet size the server will accept.

The following screenshot shows the results of setting various restrictions on the server and the value of the CONNACK Message.

You can see that you can know examine the message and know not to send QOS 2 messages for example.

Here is the section of the mosquitto.conf file:

Summary

The information sent in the connection message and the connection response message has increased greatly over that in MQTT v3.11 mainly due to to addition of the properties field in both messages.

From this overview I sure you can appreciate the increased level of control available in these new features.

For example it is possible now to tell the server:

The maximum packet size the client can accept
Request the maximum QOS supported

and to to know in advance:

The maximum packet size the server will except
Maximum QOS supported

Rather than simply having the message discarded without notification.

Resources:

• MQTTv5 specification.

Related Tutorials:

• Paho Python MQTT Client Changes for MQTTv5 Support
• MQTTv5 Properties by Message Type
• Understanding and Using MQTTv5 Shared Subscriptions and Topics
• Understanding MQTTv5 Topic Aliases
• Examining MQTTv5 User Properties
• Understanding And Using MQTT v5 Request Response
• MQTT v 5.0 New Features Overview
• MQTTv5 Last Will and Testament