1. Brief introduction

MQTT (Message Queuing Telemetry Transport, Message Queuing Telemetry Transport Protocol) is a "lightweight" communication protocol based on the publish/subscribe mode. Year released. The biggest advantage of MQTT is that it can provide real-time and reliable message services for connecting remote devices with very little code and limited bandwidth. As a low-overhead, low-bandwidth instant messaging protocol, it has a wide range of applications in the Internet of Things, small devices, and mobile applications.

MQTT is a client-server based message publish/subscribe transport protocol. The MQTT protocol is lightweight, simple, open and easy to implement, which makes it applicable to a wide range of applications. In many cases, including constrained environments, such as: Machine-to-Machine (M2M) communication and the Internet of Things (IoT). It is widely used in communicating sensors via satellite links, occasional dial-up medical devices, smart homes, and some miniaturized devices.

2. Design Specifications

Since the IoT environment is very special, MQTT follows the following design principles:

(1) Streamlined, without adding optional functions;

(2) Publish/Subscribe (Pub/Sub) mode, which facilitates the transfer of messages between sensors;

(3) Allow users to dynamically create topics with zero operation and maintenance costs;

(4) Minimize the amount of transmission to improve transmission efficiency;

(5) Taking into account factors such as low bandwidth, high latency, and unstable networks;

(6) Support continuous session control;

(7) Understand that client computing power may be low;

(8) Provide service quality management;

(9) Assuming that the data is agnostic, the type and format of the transmitted data are not enforced, and flexibility is maintained.

3. Main Features

The MQTT protocol is a protocol designed to communicate with remote sensors and control equipment in low-bandwidth, unreliable networks. It has the following main characteristics:

(1) Use the publish/subscribe message mode to provide one-to-many message publishing and decouple the application.

This is very similar to XMPP, but the information redundancy of MQTT is much less than that of XMPP, because XMPP uses XML format text to transfer data.

(2) Message transmission with shielding of payload content.

(3) Use TCP/IP to provide network connection.

The mainstream MQTT is based on TCP connection for data push, but there is also a UDP-based version called MQTT-SN. The advantages and disadvantages of these two versions are naturally different due to different connection methods.

(4) There are three message publishing service qualities:

"At most once", message publishing relies entirely on the underlying TCP/IP network. Message loss or duplication can occur. This level can be used in the case of environmental sensor data, it doesn't matter if one read record is lost, because there will be a second transmission soon. This method is mainly for the push of ordinary APP. If your smart device is not connected to the Internet when the message is pushed, and the push has not been received in the past, it will not be received when it is connected to the Internet again.

"At least once" ensures that messages arrive, but message duplication may occur.

"Only Once" ensures that the message arrives once. This level can be used in some more demanding billing systems. In billing systems, duplicate or lost messages can lead to incorrect results. This highest-quality message publishing service can also be used to push instant messaging apps to ensure that users receive and only receive it once.

(5) Small transmission, small overhead (fixed-length header is 2 bytes), and protocol switching is minimized to reduce network traffic.

This is why it is said in the introduction that it is very suitable for "communication between sensors and servers, and information collection in the field of Internet of Things". It is necessary to know that the computing power and bandwidth of embedded devices are relatively weak, and it is suitable to use this protocol to transmit messages. However.

(6) A mechanism for notifying all parties involved of client abnormal interruption using the Last Will and Testament features.

Last Will: The last word mechanism, used to notify other devices under the same topic that the device that sent the last words has been disconnected.

Testament: The testament mechanism, similar in function to Last Will.

Fourth, the principle of MQTT protocol

4.1 MQTT protocol implementation

Implementing the MQTT protocol requires communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: publisher (Publish), broker (Broker) (server), and subscriber (Subscribe). The publisher and subscriber of the message are both clients, the message broker is the server, and the message publisher can be a subscriber at the same time.

The message transmitted by MQTT is divided into two parts: topic (Topic) and payload (payload):

(1) Topic, which can be understood as the type of message, after the subscriber subscribes (Subscribe), it will receive the message content (payload) of the topic;

(2) Payload, which can be understood as the content of the message, refers to the specific content to be used by the subscriber.

4.2 Network Transmission and Application Messages

MQTT will build the underlying network transport: it will establish a client-to-server connection, providing an ordered, lossless, byte-stream-based bidirectional transmission between the two.

When application data is sent over the MQTT network, MQTT associates the quality of service (QoS) associated with it with the topic name (Topic).

4.3MQTT client

An application or device that uses the MQTT protocol, it always establishes a network connection to the server. Clients can:

(1) Publish information that other clients may subscribe to;

(2) Subscribe to messages published by other clients;

(3) Unsubscribe or delete messages from the app;

(4) Disconnect from the server.

4.4 MQTT server

The MQTT server is called a "message broker" (Broker), which can be an application or a device. It is located between message publishers and subscribers, it can:

(1) Accept network connections from customers;

(2) Accept application information released by customers;

(3) Processing subscription and unsubscription requests from clients;

(4) Forward application messages to subscribed clients.

4.5 Subscriptions, Topics, Sessions in the MQTT Protocol

1. Subscription

Subscription includes topic filter (Topic Filter) and maximum quality of service (QoS). Subscriptions are associated with a Session. A session can contain multiple subscriptions. Each subscription in each session has a different topic filter.

2. Session

After each client establishes a connection with the server, it is a session, and there is a stateful interaction between the client and the server. A session exists between a network and may span multiple consecutive network connections between a client and server.

3. Topic Name

Connect to an application message's tag that matches the server's subscription. The server will send the message to every client that subscribes to the matching tag.

4. Topic Filter

A wildcard filter on topic names, used in subscription expressions, to represent multiple topics matched by the subscription.

5. Payload

The content specifically received by the message subscriber.

4.6 Methods in the MQTT protocol

Some methods (also called actions) are defined in the MQTT protocol to express operations on certain resources. This resource can represent pre-existing data or dynamically generated data, depending on the server implementation. Typically, a resource refers to a file or output on a server. The main methods are:

(1) Connect. Waiting for a connection to be established with the server.

(2) Disconnect. Wait for the MQTT client to finish its work and disconnect the TCP/IP session from the server.

(3) Subscribe. Wait for the subscription to complete.

(4) UnSubscribe. Waits for the server to cancel the client's subscription to one or more topics.

(5) Publish. The MQTT client sends a message request and returns to the application thread after sending.

5. MQTT protocol packet structure

In the MQTT protocol, an MQTT packet consists of three parts: a fixed header (Fixed header), a variable header (Variable header), and a message body (payload). The MQTT packet structure is as follows:

(1) Fixed header. Exists in all MQTT data packets, indicating the type of the data packet and the grouping class identifier of the data packet.

(2) Variable header (Variable header). Exists in some MQTT packets, and the packet type determines whether the variable header exists and its specific content.

(3) Message body (Payload). Exists in some MQTT packets, indicating the specific content received by the client.

5.1 MQTT fixed header

Fixed headers are present in all MQTT packets and have the following structure:

5.1.1 MQTT packet types

Position: bits 7-4 in Byte 1.

Compared with a 4-bit unsigned value, the type, value and description are as follows:

5.1.2 Identification bit

Position: bits 3-0 in Byte 1.

In message types that do not use flag bits, flag bits are reserved. If an invalid flag is received, the receiver MUST close the network connection:

(1) DUP: A copy of the published message. It is used to ensure the reliable transmission of the message. If it is set to 1, the MessageId will be added to the following variable length, and a reply confirmation is required to ensure the completion of the message transmission, but it cannot be used to detect the repeated transmission of the message.

(2) QoS: The quality of service for publishing messages, that is: the number of times the message is guaranteed to be delivered

         Ø00：最多一次，即：<=1

        Ø01：至少一次，即：>=1

        Ø10：一次，即：=1

        Ø11：预留

(3) RETAIN: Publishing reservation identifier, indicating that the server wants to retain the information pushed this time. If a new subscriber appears, it will push the message to it. If there is, it will be pushed to the current subscriber and released.
5.1.3 Remaining Length

Address: Byte 2.

The second byte of the fixed header is used to store the total size of the variable-length header and message body, but not directly. This byte can be extended, and its storage mechanism, the first 7 bits are used to save the length, and the latter is used for the identification. When the last bit is 1, it indicates that the length is insufficient, and two bytes need to be used to continue to save. For example: Calculate the size of the back as 0

5.2 MQTT variable header

MQTT packets contain a variable header that resides between the fixed header and the payload. The content of the variable header varies according to the type of data packet, and the most common application is as a packet identifier:

Many types of packets include a 2-byte packet identification field. These types of packets are: PUBLISH (QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.

5.3 Payload message body

The Payload message is the third part of the MQTT data packet, including four types of messages: CONNECT, SUBSCRIBE, SUBACK, and UNSUBSCRIBE:

(1) CONNECT, the main content of the message body is: ClientID of the client, subscribed Topic, Message, user name and password.

(2) SUBSCRIBE, the content of the message body is a series of topics to be subscribed and QoS.

(3) SUBACK, the content of the message body is that the server confirms and replies to the subject and QoS applied by SUBSCRIBE.

(4) UNSUBSCRIBE, the content of the message body is the topic to be subscribed to.

MQTT--Getting Started