Translator: Tnecesoc, this member is from Cloud+Community Translation Agency
Message Queuing Telemetry Transport (MQTT) is a client-server publish/subscribe messaging protocol. It's lightweight, open, and simple, and its design is easy to implement. These features make it ideal for use in many situations, including in environments with limited network connectivity, where code size is small and/or network bandwidth is critical, such as in machine-to-machine (M2M) and Internet of Things (IoT) environments communication in. The protocol operates over TCP/IP or other network protocols that provide an orderly, lossless, two-way connection.
MQTT supports three quality of service levels, as shown in the figure above:
Send at most once (forget after sending), that is, do not confirm
Sent at least once, confirmation required
Send exactly once, with a 4-step handshake
QoS (Quality of Service) defines the way a server (Broker) / client (Client) ensures that a message is received or attempted. Messages can be sent at any QoS level, and clients can choose to subscribe to topics at any QoS level, the latter choosing the highest QoS level they can receive.
For example, if a message is published with QoS level 2 and a client subscribes to the topic with QoS level 0, that client will receive the message with QoS level 0. If there is a second client also subscribed to the same topic, but with QoS 2, it will receive the message at QoS 2 level.
As another example, if a client subscribes to a topic with QoS 2, and a message is published on the corresponding topic with QoS 0, the client will receive the message based on the QoS 0 level. Advanced QoS is more reliable, but it also brings higher latency and consumes more bandwidth.
Some details of each QoS level are shown below. A table of MQTT control packet contents is at the end of this article describing the control packets from each QoS flow.
Quality of service level 0
The message is sent at most once, or not sent at all when transmission over the network is blocked. Sent messages are not saved. If the client disconnects, or if the server fails, the message may be lost. This is also the fastest transfer mode. The MQTT protocol does not require the server to forward the published message with QoS = 0 to the client. Depending on the server, if the client disconnects when the server receives a published message, the published message may be discarded. The Telemetry (MQXR) service does not drop messages sent with QoS = 0. They are kept as non-persistent messages and are only discarded when the queue manager stops functioning.
In the QoS 0 transport protocol:
Sender: must send PUBLISH packet with QoS = 0, DUP = 0;
Receiver: Receives ownership of the message while receiving the PUBLISH packet.
Quality of Service Level 1
The message is sent at least once. If the sender does not receive the acknowledgment packet, it will send the message with the DUP flag again until the acknowledgment packet is received. Therefore, the recipient may send the same message several times, and may also process it several times. The message must be kept in the sender's and receiver's local environment until the message is properly processed. The receiver deletes the message after processing the message. If the receiver is a server, it will publish the message to its subscribers as processing of the message. If the recipient is a client, the message will be delivered to the subscriber's application for processing. After the message is deleted, the receiver sends an acknowledgment packet to the sender. The sender will delete the message saved in the sender after receiving the confirmation from the receiver.
This level can be used to transmit data such as environmental sensors. In this case, it doesn't matter that the transmission of a single reading fails because the sensor will send the reading again soon.
In the QoS 1 transport protocol:
sender:
An unused bundle identifier must be assigned each time a new application message is published.
A PUBLISH packet must be sent with a packet identifier of QoS = 1, DUP = 0.
A PUBLISH packet MUST be considered "unacknowledged" until it receives a corresponding PUBACK packet from the receiver.
Once the sender receives the PUBACK packet, the packet identifier of the corresponding message can be retrieved and reused. Note that the sender can send more PUBLISH packets with different packet identifiers while it is waiting for an acknowledgment of receipt.
receiver:
After accepting ownership of the application message, it MUST respond with a PUBACK packet containing the packet identifier of the incoming PUBLISH packet.
After sending a PUBACK packet, the receiver MUST treat each incoming PUBLISH packet containing the same packet identifier as a new publish message, regardless of whether these publish messages are marked with DUP.
Quality of Service Level 2
The message is always sent only once. The message must be stored in the sender's and receiver's local environment until it is properly handled. QoS = 2 is the safest but also the slowest transfer mode. At least two mutual transmissions are required between the sender and receiver before the message can be deleted from the sender. After the first transmission, the receiver can start processing the message. In the first transfer, the sender sends a message and gets an acknowledgment of the message from the receiver. If the sender does not receive an acknowledgment, the message is sent again with the DUP flag until an acknowledgment is received. In the second transfer, the sender informs the receiver that it can finish processing the published message by sending a PUBREL message to the receiver. If the sender does not receive the acknowledgment of the PUBREL message from the receiver, it will send the PUBREL message again until an acknowledgment is received. When the sender receives an acknowledgment for the PUBREL message, the sender deletes the message it saved. The receiver can process the message on the first or second pass, as long as it doesn't reprocess the message again. If the receiver is the server, it will publish the message to the subscribers. If the receiver is a client, it will deliver the message to the application that is the subscriber. Finally, the receiver will send a processed message to the sender to indicate that it has finished processing the message.
For example, billing systems may use this level, since duplication or loss of messages could cause such applications to generate erroneous billing.
In the QoS 2 transport protocol:
sender:
An unused bundle identifier must be assigned each time a new application message is published.
A PUBLISH packet containing a packet identifier with QoS = 2, DUP = 0 MUST be sent.
A PUBLISH packet MUST be considered "unacknowledged" until it has received a corresponding PUBREC packet from the receiver.
When it receives a PUBREC packet from the receiver, it must send a PUBREL packet. This PUBREL packet SHOULD contain the same packet identifier as the original PUBLISH packet.
A PUBREL packet MUST be considered "unacknowledged" until it has received a corresponding PUBCOMP packet from the receiver.
Once the corresponding PUBREL packet has been sent, the sender can no longer send the original PUBLISH packet. Once the sender receives the PUBCOMP packet, the packet identifier can be recovered and reused. Note that while the sender is waiting for an acknowledgment to receive, it can send more PUBLISH packets with different packet identifiers.
receiver:
After accepting ownership of the PUBLISH packet's application message, it MUST respond with a PUBREC packet containing the packet identifier of the incoming PUBLISH packet.
Before the receiver receives the corresponding PUBREL packet, it must acknowledge by sending a PUBREC packet for each subsequent PUBLISH packet with the same packet identifier as the incoming PUBLISH packet. It MUST NOT allow a duplicate message to be passed to any downstream receiver.
After receiving a PUBREL packet from the sender, it MUST respond by sending a PUBCOMP packet containing the same packet identifier as PUBREL.
After sending a PUBCOMP packet, the receiver MUST treat any subsequent PUBLISH packet with the same packet identifier as the incoming PUBLISH packet as a completely new publish message.
Details of MQTT control packets
| control package | sending direction | describe |
|---|---|---|
| CONNECT | Client -> Server | The client requests to establish a connection with the server |
| CONNACK | Server -> Client | Connection established successfully |
| PUBLISH | Client -> Server / Server -> Client | make an announcement |
| PUBACK | Client -> Server / Server -> Client | Receive confirmation of published message |
| PUBREC | Client -> Server / Server -> Client | Received release message (2nd handshake for QoS 2) |
| PUBREL | Client -> Server / Server -> Client | No more messages (third handshake for QoS 2) |
| PUBCOMP | Client -> Server / Server -> Client | The end of the message publishing (the fourth handshake of QoS 2) |
| SUBSCRIBE | Client -> Server | Client requests to subscribe to a topic |
| SUBACK | Server -> Client | Subscription operation succeeded |
| UNSCBSCRIBE | Client -> Server | Client requests to unsubscribe from a topic |
| UNSCBACK | Server -> Client | Unsubscribe operation succeeded |
| PINGREQ | Client -> Server | PING request |
| PINGRESP | Server -> Client | PING response |
| DISCONNECT | Client -> Server | The client disconnected from the server |
references
OASIS Documentation:
Some content was adapted from BB Smartworx and IBM Developer Work.
The copyright of this article belongs to Tnecesoc , if you need to reprint, please contact the author.
Q&A
Difficulties and doubts in the application of IoT technology in smart cities?
Related Reading
Everything you need to start an IoT project
How the Internet of Things is Enhancing Pervasive Computing
