MQTT Protocol

Message Queuing Telemetry Transport (MQTT) is an acronym for Message Queuing Telemetry Transport. MQTT is a machine-to-machine connectivity protocol for the internet of things. It’s a publish-subscribe messaging transport protocol that’s extremely light.

This protocol is beneficial when connecting to a remote location where bandwidth is limited. These characteristics make it useful in a variety of situations, including a constant environment like machine-to-machine communication and internet of things scenarios.

It’s a publish-and-subscribe system that allows us to send and receive messages as clients. It makes communication between multiple devices simple. It’s a simple messaging protocol designed for devices with limited resources and low bandwidth, making it ideal for internet of things applications.

Characteristics of MQTT:

1. It’s a machine-to-machine protocol, which means it allows devices to communicate with one another.
2. It’s a simple, lightweight messaging protocol that uses a publish/subscribe system to send and receive data between the client and the server.
3. It is not necessary to establish a connection between the client and the server at the same time.
4. It allows for faster data transmission, similar to how WhatsApp/messenger allows for quicker delivery. It’s a protocol for sending messages in real time.
5. It allows customers to subscribe to a limited number of topics in order to receive the information they require.

History of MQTT:

Dr. Andy Stanford-Clark, IBM, and Arlen Nipper created the MQTT protocol. Under MQTT ORG, previous versions of protocol 3.1 and 3.1.1 were made available. The MQTT was officially published by OASIS in 2014. The OASIS became the new home for MQTT development. The OASIS then began further development of the MQTT protocol. Version 3.1.1 is backward compatible with 3.1 and includes only minor changes such as a new connect message and clarification of the 3.1 version. MQTT 5.0 is the most recent version, and it is a successor to MQTT 3.1.1. Version 5.0 does not have the same backward compatibility as version 3.1.1. Version 5.0, according to the specifications, has a large number of features that help to keep the code in place.

MQTT Architecture:

There are many components which together form the foundation of the MQTT protocol. The components are as follows:

1. Message:

The message is the data that is carried out by the protocol across the network for the application. When the message is transmitted over the network, then the message contains the following parameters:

a. Payload
b. Collection of Properties
c. Quality of Service (QoS)
d. Topic Name

2. Client:

Subscriber and publisher are the two roles of a client in MQTT. Clients subscribe to topics in order to send and receive messages. In simple terms, any programme or device that uses a MQTT is referred to as a client. If a device opens a network connection to the server, publishes messages that other clients want to see, subscribes to the messages it wants to receive, unsubscribes from the messages it doesn’t want to receive, and closes the network connection to the server, it is considered a client.

The client in MQTT performs two tasks:

a. Publish:

An operation is termed as a publish operation when the client sends data to the server.

b. Subscribe:

An operation is called a subscribe operation when the client receives data from the server.

3. Server or Broker:

The device or programme that allows the client to both publish and subscribe to messages. A server accepts the client’s network connection, accepts the client’s messages, processes subscribe and unsubscribe requests, forwards application messages to the client, and closes the client’s network connection.

4. Topic:

 

The message’s label is compared to the TOPIC subscription that the server is aware of.

MQTT Message Format:

The command and command acknowledgment format is used by MQTT, which means that each command has an accompanying acknowledgement. The connect command has connect acknowledgment, the subscribe command has subscribe acknowledgment, and the publish command has publish acknowledgment, as shown in the diagram above. This mechanism is similar to the TCP protocol’s handshaking mechanism.

MQTT Packet Structure:

The MQTT message format includes a two-byte fixed header that appears in all MQTT packets. A variable header is the second field, which is not always present. A payload is the third field, which is not always present. The data that is being sent is stored in the payload field. We may believe that the payload is a required field, but this is not the case. Some commands, such as disconnect message, do not use the payload field.

MQTT Fixed Header Format:

The fixed header contains 2 bytes, and the first byte has these fields:

1. MQTT Control Packet Type:

It takes up four bits, or seven to four bits. Each bit represents the MQTT control packet type and is assigned to this 4-bit value.

2. Flag specific to each MQTT Packet Type:

The remaining 4-bits represent MQTT packet type-specific flags.

The remaining length is stored in byte 2, which is a variable-length byte integer. The number of bytes left in a current control packet, including data in the variable header and payload, is represented by this value. As a result, the length remaining is equal to the sum of the data in the variable header and the payload.

MQTT Control Packet Types:

Name	Value	Direction of Flow	Description
Reserved	0	Forbidden	Reserved
CONNECT	1	Client To Server	Connection Request
CONNACK	2	Server To Client	Connection Acknowledgement
PUBLISH	3	Client To Server Or Server To Client	Publish Message
PUBACK	4	Client To Server Or Server To Client	Publish Acknowledgement
PUBREC	5	Client To Server Or Server To Client	Publish Received
PUBREL	6	Client To Server Or Server To Client	Publish Release
PUBCOMP	7	Client To Server Or Server To Client	Publish Complete
SUBSCRIBE	8	Client To Server	Subscribe Request
SUBACK	9	Server To Client	Subscribe Acknowledgement
UNSUBSCRIBE	10	Client To Server	Unsubscribe request
UNSUBACK	11	Server To Client	Unsubscribe Acknowledgement
PINGREQ	12	Client To Server	Ping Request
PINGRESP	13	Server To Client	Ping Response
DISCONNECT	14	Client To Server Or Server To Client	Disconnect Notification
AUTH	15	Client To Server Or Server To Client	Authentication Exchange

Flag Bit:

MQTT Control Packet	Fixed Header Flags	Bit 3	Bit 2	Bit 1	Bit 0
CONNECT	Reserved	0	0	0	0
CONNACK	Reserved	0	0	0	0
PUBLISH	MQTT v5.0	DUP	QoS		RETAIN
PUBACK	Reserved	0	0	0	0
PUBREC	Reserved	0	0	0	0
PUBREL	Reserved	0	0	0	0
PUBCOMP	Reserved	0	0	0	0
SUBSCRIBE	Reserved	0	0	0	0
SUBACK	Reserved	0	0	0	0
UNSUBSCRIBE	Reserved	0	0	0	0
UNSUBACK	Reserved	0	0	0	0
PINGREQ	Reserved	0	0	0	0
PINGRESP	Reserved	0	0	0	0
DISCONNECT	Reserved	0	0	0	0
AUTH	Reserved	0	0	0	0

Remaining Length:

The remaining length is a variable-length integer that indicates the number of bytes left in the current control packet, including the variable header and payload data. As a result, the remaining length is equal to the variable header data plus the payload.

The remaining length is equal to the length of the variable header plus the length of the payload.

The remaining length can be up to 4 bytes long, and it starts at 2 bytes and can go up to 4 bytes long.

The lengths in this field are 7-bit, and the MSB bit can be used to continue a flag. The next byte is included in the remaining length if the continuation flag is set to 1. A byte is the last one of the remaining length if the continuation flag is 0.

Variable Header:

A variable header component is included in some MQTT control packet types as an optional field. Between the fixed header and the payload is this field. The variable header’s content is determined by the packet type. The packet identifier field, which is common in many packet types, is found in the variable header. The packet identifier field, a 2-byte integer, is included in the variable header component of many MQTT control packet types.

The packet identifier field is given in the list below:

• PUBLISH
• PUBACK
• PUBREC
• PUBREL
• PUBCOMP
• SUBSCRIBE
• SUBACK
• UNSUBSCRIBE
• UNSUBACK

Characteristics of the Packet Identifier Field:

1. If the value of QoS (Quality of Service) is set to zero, a PUBLISH packet should not contain the packet identifier field. It means that if the QoS value is greater than zero, the packet identifier field will only be present in the PUBLISH packet.

2. A client should assign a non-zero packet identifier that is currently unused when sending a new SUBSCRIBE, UNSUBSCRIBE, or PUBLISH MQTT control packet.

3. A server should assign a non-zero packet identifier that is currently unused when sending a new PUBLISH MQTT control packet.

4. PUBACK, PUBREC, PUBUREL, and PUBREC are PUBLISH command acknowledgment packets with the same packet identifier as the PUBLISH packet.

5. SUBACK and UNSUBACK are the SUBSCRIBE and UNSUBSCRIBE acknowledgment packets, respectively. The SUBACK and UNSUBACK packets share the same packet identifier as the SUBSCRIBE and UNSUBSCRIBE packets.

6. After processing the corresponding acknowledgment packet, the packet identifier can be reused. The following is a definition:

a. If QoS is set to 1, the acknowledgement packet for PUBLISH will be PUBACK. If the PUBACK is processed, the PUBACK packet identifier can be reused.

b. If the QoS value is 2, the PUBLISH acknowledgement packet will be PUBCOMP or PUBREC.

Payload:

The payload is the last MQTT control packet in the ICMP message format. This field holds the data that will be sent.

MQTT Control Packet	Payload
CONNECT	Required
CONNACK	None
PUBLISH	Optional
PUBACK	None
PUBREC	None
PUBREL	None
PUBCOMP	None
SUBSCRIBE	Required
SUBACK	Required
UNSUBSCRIBE	Required
UNSUBACK	Required
PINGREQ	None
PINGRESP	None
DISCONNECT	None
AUTH	None

Summary:

In this article, we looked at the concept and functioning of the MQTT Protocol. We looked at the architecture of the MQTT Protocol, as well as the message format and structure of the MQTT header. We also took a detailed look at the various fields present in the MQTT header.