MQTTv5 CONNECT and CONNACK Messages -Overview

mqttv5-connectThe 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 size the client will accept.

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.

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

Protocol Name and Version

This 1 byte field is identical to that of MQTTv3.1.1 except in contains MQTTv5 version number.

Connect Flags

The one byte connect flags field is 1 byte with the bits representing flags. The flags are:

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

This field is identical to that of version 3.1.1

Keep Alive Duration

Two bytes to encode the keep alive duration maximum value of 65,535 seconds =18 hours 12 mins and 15 secs.

This field is identical to that of version 3.1.1

 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.

Fields are optional and may not be present.

Session Expiry Interval
Receive Maximum
Maximum Packet Size
Topic Alias Maximum
Request Response Information
Request Problem Information
User Properties
Authentication Method
Authentication Data

Connect Payload

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.

Note: Listed in order sent

Client Identifier ( ClientID )

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

Important Connection Property Fields

Maximum Packet Size

This is used to restrict the size of messages that the server can send to the client.

Topic Alias Maximum

Limits the number of topic aliases that the client will hold.

Request Response Information

This is used to request the server to send response information the the CONNACK packet.

Request Problem Information

Used to request reason codes in case of connection failure.

User Property

Another important addition that allows applications to send user data as key value pairs.

Authentication Method

Used to indicate the type of authentication used. This means other authentication methods are now available other than user name and password in MQTTv3.11

Authentication Data

Contents depend on the method set above.

 

CONNACK– Connection Acknowledge

The Connection Message will be acknowledged

This consists of two parts:

  • Fixed Header
  • Variable Header

Fixed Header

This is two to four bytes. The first byte contains the Message Control Packet Type (CONNACK) 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 CONNACK variable header contains:

  • Connect Acknowledge flags
  • Connect Reason Code
  • Properties

Connect Acknowledge flags

1 Byte field and only one bit used to indicate a session present or not (session present flag)

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.

Session Expiry Interval
Receive Maximum
Maximum QoS
Retain Available
Maximum Packet Size
Assigned Client Identifier
Topic Alias Maximum
Reason String
User Property
Wildcard Subscription Available
Subscription Identifiers Available
Shared Subscription Available
Server Keep Alive
Response Information
Authentication Methods
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.

connack-properties-example
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:

mosquitto.conf-file-v5

Summary

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

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:

Related Tutorials:

 

Please rate? And use Comments to let me know more
[Total: 1    Average: 3/5]

Leave a Reply

Your email address will not be published. Required fields are marked *