-
mqtt protocol -
1 MQTT Protocol Features -
Publish and Subscribe -
QoS (Quality of Service levels) -
2 MQTT Packet Structure -
2.1 MQTT Fixed Header -
2.2 MQTT Variable Header -
2.3 Payload Message Body -
3 Environment Setup -
3.1 Setting up MQTT Server -
3.2 MQTT Client -
4 Summary
As a low-overhead, low-bandwidth instant messaging protocol, it has a wide range of applications in the IoT, small devices, and mobile applications.
The MQTT protocol is lightweight, simple, open, and easy to implement, which makes it applicable in a wide range of scenarios, including constrained environments such as machine-to-machine (M2M) communication and the Internet of Things (IoT).
It has been widely used in applications such as satellite-linked communication sensors, occasional dial-up medical devices, smart homes, and some miniaturized devices.
The current version of the MQTT protocol is MQTT v3.1.1, released in 2014. In addition to the standard version, there is a simplified version called MQTT-SN, which is primarily aimed at embedded devices that typically operate on TCP/IP networks, such as ZigBee.
MQTT, like HTTP, runs on top of the Transmission Control Protocol/Internet Protocol (TCP/IP) stack.
Publish and Subscribe
MQTT uses a publish/subscribe messaging model, providing a one-to-many messaging distribution mechanism, which decouples it from the applications.
This is a messaging pattern where messages are not sent directly from the sender to the receiver (i.e., point-to-point), but are distributed by the MQTT server (also known as the MQTT Broker).
The MQTT server is the core of the publish-subscribe architecture.
It can be implemented very simply on single-board computers like Raspberry Pi or NAS, and it can also be implemented on mainframes or Internet servers.
The server distributes messages, so it must be the publisher, but never the subscriber!
Clients can publish messages (senders), subscribe to messages (receivers), or do both.
A client (also known as a node) is an intelligent device, such as a microcontroller or a computer that has a TCP/IP stack and implements MQTT protocol software.
Messages are published under topics that allow filtering. Topics are hierarchical UTF-8 strings. Different topic levels are separated by slashes (/).
Let’s take a look at the following setup.
-
The photovoltaic power station is the publisher. -
The main topic level is “PV”, and this factory publishes two sub-levels “sunshine” and “data”; -
“PV/sunshine” is a boolean value (true/fault, which can also be 1/0), and the charging station needs it to know whether to load the electric vehicle (only when it is sunny 🙂 ). -
The charging station (EVSE) is the subscriber, subscribing to “PV/sunshine” to get information from the server. -
On the other hand, “PV/data” transmits the instantaneous power generated by the plant in kW, and this topic can be subscribed to, for example, by a computer or tablet to generate a chart of the power transmitted throughout the day.
This is a simple application scenario of MQTT, as shown in the figure below;
MQTT Publish and Subscribe
QoS (Quality of Service Levels)
Quality of Service is an important feature of MQTT. When we use TCP/IP, the connection is already protected to some extent. However, in wireless networks, interruptions and interferences are frequent, and MQTT helps avoid information loss and its quality of service levels. These levels are used during publishing. If a client publishes to the MQTT server, the client will be the sender, and the MQTT server will be the receiver. When the MQTT server publishes messages to the client, the server is the sender, and the client is the receiver.
QoS 0
This level may experience message loss or duplication, and message publication depends on the underlying TCP/IP network. That is: <=1
QoS 1
QoS 1 guarantees that the message will be delivered at least once to the subscriber.
QoS 2
With QoS 2, we guarantee that the message is delivered to the destination exactly once. To do this, messages with a unique message ID are stored twice, first by the sender and then by the receiver. QoS level 2 has the highest overhead in the network because two flows are needed between the sender and the receiver.
-
Fixed Header (Fixed header) exists in all MQTT packets, indicating the packet type and the grouping class identifier; -
Variable Header (Variable header), exists in some MQTT packets, the packet type determines whether the variable header exists and its specific content;
-
Message Body (Payload), exists in some MQTT packets, indicating the specific content received by the client;
The overall message format of MQTT is shown in the figure below;
2.1 MQTT Fixed Header
The fixed header exists in all MQTT packets, and its structure is as follows:
Let’s briefly analyze the message format of the fixed header;
MQTT Message Type
**Location:** byte 1, bits 7-4.
A 4-bit unsigned value, types are as follows:
Identifier / DUP
**Location:** byte 1, bits 3-0.
In message types that do not use the identifier, the identifier is reserved. If an invalid flag is received, the receiving end must close the network connection:
-
DUP: A copy of the published message. Used to ensure reliable message transmission. If set to 1, the MessageId is added in the variable length below, and a confirmation reply is required to ensure message transmission is completed, but it cannot be used to detect message duplication.
-
QoS: The quality of service for publishing the message (already introduced above), that is: the number of guaranteed message deliveries
-
RETAIN: The retained message flag indicates that the server should retain this pushed information. If a new subscriber appears, the server will push this message to it; if set, it will be released after pushing to the current subscriber.
Remaining Length
Location: byte 1.
The second byte of the fixed header is used to save the total size of the variable header and message body, but it is not saved directly. This byte can be extended, and its saving mechanism uses the first 7 bits to save the length and the last part as an identifier. When the last bit is 1, it indicates that the length is insufficient and requires two bytes to continue saving. For example: if the calculated size is 0
2.2 MQTT Variable Header
The MQTT packet contains a variable header, which is located between the fixed header and the payload. The content of the variable header varies by packet type, and a common application is to serve as the packet identifier:
Many types of packets include a 2-byte packet identifier field, including the following types of packets:
PUBLISH (QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP,
SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK
2.3 Payload Message Body
The payload message body is the third part of the MQTT packet, and the CONNECT, SUBSCRIBE, SUBACK, and UNSUBSCRIBE message types have a message body:
-
CONNECT, the message body mainly includes: ClientID, subscribed Topic, Message, and username and password
-
SUBSCRIBE, the message body includes a series of topics to be subscribed to and their QoS.
-
SUBACK, the message body is the server’s confirmation and reply to the requested topics and QoS from SUBSCRIBE.
-
UNSUBSCRIBE, the message body includes the topics to unsubscribe.
[Image link failed, the source site may have anti-leech mechanism, it is recommended to save the image and upload directly (Architecture diagram.png)]
3.1 Setting up MQTT Server
Currently, the mainstream platforms for MQTT brokers include the following:
-
Mosquitto: https://mosquitto.org/
-
VerneMQ: https://vernemq.com/
-
EMQTT: http://emqtt.io/
This article will use Mosquitto for testing. Go to the installation page and download the program compatible with your computer’s operating system;
After successful installation, navigate to the installation path and find mosquitto.exe;
[Image link failed, the source site may have anti-leech mechanism, it is recommended to save the image and upload directly (image-20210705171401654.png)]
Hold Shift, right-click in the empty space, and then open PowerShell, or just open a terminal software normally;
-
Input ./mosquitto.exe -h to see the corresponding help;
-
Input ./mosquitto.exe -p 10086 to start the MQTT service, listening at127.0.0.1 on port10086;
As shown in the figure below;
3.2 MQTT Client
Now that the server is set up, the next step is to start the client to publish and subscribe, allowing for message transmission.
Here, I am using a QT MQTT client program that I compiled myself, based on the official Qt library. Below, I will briefly introduce how to complete this client and set the corresponding parameters:
-
Address: 127.0.0.1
-
Port: 10086
Then subscribe to the topic, and you can send data to each other, as shown in the figure below;
Combining with the previous image, the overall architecture is shown below;
This article briefly introduced the working principle of the MQTT protocol, the corresponding protocol format, and some details of the protocol, providing specific application scenarios. The author’s level and ability are limited, and there may be errors and omissions in the text. Please feel free to provide guidance.
Scan to access the download center directly
Click“Read the original text” to upload materials!