One, a brief introduction
MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol based on publish/subscribe mode. MQTT is based on TCP/IP. Released by IBM in 1999. The biggest advantage of MQTT is that it can provide real-time, reliable messaging services for connecting remote devices with very little code and limited bandwidth. As an instant messaging protocol with low overhead and bandwidth consumption, it is widely used in Internet of Things, small devices, mobile applications and so on.
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, this includes constrained environments such as machine-to-machine (M2M) communication and the Internet of Things (IoT). It is already widely used in sensors that communicate via satellite links, in medical devices that occasionally dial up, in smart homes, and in small devices.
Ii. Design specifications
Because the environment of the Internet of Things is very specific, MQTT follows the following design principles:
(1) Streamlining, without adding optional functions;
(2) Publish/subscribe (Pub/Sub) mode to facilitate message transmission between sensors;
(3) Allow users to dynamically create themes, zero operation and maintenance costs;
(4) Reduce the transmission volume to the minimum to improve transmission efficiency;
(5) Consider factors such as low bandwidth, high latency and unstable network;
(6) Support continuous session control;
(7) Understand that the computing power of the client may be low;
(8) To provide service quality management;
(9) Assume that the data is unknowable, do not force the type and format of transmitted data, and maintain flexibility.
Three, the main characteristics
MQTT protocol is a protocol designed to communicate with remote sensors and control devices over low-bandwidth, unreliable networks. It has the following main characteristics:
(1) Use publish/subscribe message pattern to provide one-to-many message publishing and release application coupling.
This is similar to XMPP, but MQTT has much less information redundancy than XMPP, because XMPP uses XML-formatted text to pass data.
(2) Message transmission shielded from payload content.
(3) Use TCP/IP to provide network connections.
The mainstream MQTT is based on TCP connections for data push, but there is also a UDP-based version called MQTT-SN. The two versions have different advantages and disadvantages due to the different connection methods.
(4) There are three qualities of message publishing service:
“At most once”, message publishing is entirely dependent on the underlying TCP/IP network. Message loss or duplication occurs. This level can be used for environmental sensor data where the loss of a read record does not matter because a second send will follow shortly after. This method is mainly for ordinary APP push. If your smart device is not connected to the Internet when the message is pushed, it will not receive the message when it is pushed 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 more stringent billing systems. In billing systems, message duplication or loss can result in incorrect results. This highest quality messaging service can also be used for instant messaging apps to ensure that users receive it and only receive it once.
(5) Small transmission, low overhead (fixed length header is 2 bytes), protocol exchange 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 the Internet of Things”. Considering that the computing power and bandwidth of embedded devices are relatively weak, this protocol is the most suitable for transmitting messages.
(6) Mechanisms for notifying parties of client outages using the Last Will and Testament features.
Last Will: The Last message mechanism, used to notify other devices in the same topic that the device that sent the Last message has disconnected.
39, Testament: a Testament mechanism similar to Last Will.
Four, MQTT protocol principle
4.1 Implementation of MQTT protocol
The implementation of MQTT protocol requires the communication between the client and the server. In the communication process, MQTT protocol has three identities: Publish, Broker and Subscribe. Where the publisher and subscriber of a message are both clients, the message broker is a server, and the publisher can be both subscribers.
The messages transmitted by MQTT are divided into Topic and payload.
(1) Topic, which can be interpreted as the type of message. After a subscriber subscribes, he/she receives a message payload of the Topic.
(2) The payload is the specific content that subscribers use.
4.2 Network Transmission and Application Messages
MQTT builds the underlying network transport: it establishes a client-to-server connection, providing an ordered, lossless, bidirectional byte stream based transport between the two.
When requested data is sent over the MQTT network, the MQTT associates the associated quality of service (QoS) with the Topic name (Topic).
4.3 the MQTT client
An application or device using the MQTT protocol that always establishes a network connection to the server. The client can:
(1) Publish information that other clients may subscribe to;
(2) Subscribe to messages published by other clients;
(3) Message of unsubscribing or deleting the application;
(4) Disconnect from the server.
4.4 MQTT Server
An MQTT server, called a “message Broker,” can be an application or a device. It is located between the message publisher and the subscriber. It can:
(1) Accept network connections from customers;
(2) Accept application information released by customers;
(3) Handle subscription and unsubscribe requests from clients;
(4) Forward application messages to subscribing customers.
4.5 Subscriptions, topics, and sessions in MQTT
Subscription
Subscriptions contain Topic filters and maximum Quality of Service (QoS). The subscription is associated with a Session. A session can contain multiple subscriptions. Each subscription in each session has a different topic filter.
Ii. Session
After each client establishes a connection with the server, it is a session, and there is stateful interaction between the client and the server. Sessions exist across a network and may span multiple consecutive network connections between clients and servers.
3. Topic Name
The label that connects to an application message that matches the server’s subscription. The server sends a message to each client that subscribes to the matching label.
Topic Filter
A wildcard filter for topic names, used in subscription expressions to represent multiple topics matched by the subscription.
It is a Payload.
What exactly is received by the message subscriber.
4.6 Methods in MQTT protocol
The MQTT protocol defines methods (also known as actions) that represent actions to be performed on identified resources. This resource can represent pre-existing data or dynamically generated data, depending on the server’s implementation. In general, resources refer to files or output on the server. The main methods are:
(1) Connect. Waiting to establish a connection to the server.
(2) Disconnect. Wait for the MQTT client to finish what it has done and disconnect the TCP/IP session from the server.
(3) Subscribe. Wait for the subscription to complete.
(4) UnSubscribe. Wait 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 when it is finished.
5. MQTT protocol packet structure
In MQTT protocol, an MQTT packet consists of Fixed header, Variable header, and message body payload. MQTT packet structure is as follows:
(1) Fixed header). It exists in all MQTT packets and represents the packet type and packet grouping class identification.
(2) Variable headers Exists in partial MQTT packets, and the packet type determines the presence and content of the variable header.
(3) The Payload. Exists in partial MQTT packets and represents specific content received by the client.
5.1 MQTT fixed head
Fixed headers exist in all MQTT packets and are structured as follows:
5.1.1 TYPES of MQTT packets
Position: Bits 7-4 in Byte 1.
Corresponding to a 4-bit unsigned value, the type, value, and description are as follows:
5.1.2 identifies a
Position: Bits 3-0 in Byte 1.
In message types that do not use an identity bit, the identity bit is used as a reserved bit. If an invalid flag is received, the receiver must close the network connection:
(1) DUP: copies of published messages. If the value is set to 1, the MessageId is added to the variable length below and a reply is required to confirm the completion of message transmission. However, it cannot be used to detect repeated message transmission.
(2) QoS: service quality of message release, that is, the number of guaranteed message delivery
ø 00: at most once, that is: < =1 ø 01: at least once, i.e. =1 ø 10: once, that is, =1 ø 11: reservedCopy the codeRETAIN: Indicates that the server will RETAIN the information of this push. If a new subscriber appears, the server will push the message to it. If there is no new subscriber, the server will push the message to the current subscriber and release it.
5.1.3 Remaining Length
Address: Byte 2.
The second byte of the fixed header is used to hold the total size of the variable-length header and message body, but not directly. This byte is extensible and its preservation mechanism, with the first 7 bits for the length and the last for the identifier. If the last bit is 1, the length is insufficient and two bytes are required to save the file. For example, calculate the following size to be 0
5.2 MQTT variable header
The MQTT packet contains a variable header that resides between the fixed header and the payload. The contents of the variable header vary by packet type, and are more commonly used as packet identifiers:
Many types of packets contain a 2-byte packet identification field: PUBLISH (QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.
5.3 Payload Message body
Payload The third part of an MQTT packet, containing CONNECT, SUBSCRIBE, SUBACK, and UNSUBSCRIBE messages.
(1) CONNECT: Message body content mainly includes client ClientID, subscribed Topic, Message, user name and password.
(2) SUBSCRIBE, message body content is a series of topics and QoS to SUBSCRIBE.
(3) SUBACK, the message body content is that the server confirms and replies to the subject and QoS applied by SUBSCRIBE.
(4) UNSUBSCRIBE, message body content is the topic to subscribe.
Discussion address: record the problems encountered in learning, record the growth