MQTT Agreement learning Experience _MQTT

First knowledge of MQTT

To the age of the Internet of things, due to the differences in intelligent hardware, compared to Internet terminals, hardware configuration is much lower, and the environment of smart devices also want to be more complex, data transmission in the Internet will face many problems, such as in the network instability, if the guarantee data transmission no problem, how to ensure that the data is not repeatedly sent, How to reconnect when the connection is disconnected, and the HTTP protocol is not suitable for internet due to its heavy weight. So IBM is proposing a lightweight MQTT protocol for this purpose.

MQTT (Message Queuing telemetry transport) is a IoT transport protocol designed for lightweight release/subscription messaging designed to provide reliable network services for IoT devices in low-bandwidth and unstable network environments. MQTT is a lightweight transport protocol designed specifically for IoT development. MQTT protocol for low bandwidth network, low computational capacity of the equipment, made a special optimization, so that it can adapt to all kinds of things networking applications.

Today, many third-party push platforms are implemented by MQTT, and message middleware ACTIVEMQ subscription/release modules are also based on MQTT implementations. The implementation model of MQTT

MQTT Message Agent: A message server that handles requests for client subscriptions/publications
MQTT Client: Note that in the MQTT business model, both the message publisher and the message Subscriber belong to the customer, which means that a customer can either publish a message or subscribe to a message

A channel for the topic name (Topic name) to identify the information that has been published. Subscribers use it to determine the information they are interested in receiving. It is a layered structure, with a slash "/" as the separator character. There are two wildcard characters that can be used when the topic is published, subscribed: "#" and "+". The former can be mixed with multilayer structure, while the latter can only pass a layer of structure. For example, a topic: "A/B/C", then "a/+/c" and "a/#" can be equal to it. The publication does not support fuzzy matching and must be a defined topic. Service Quality

In Mqtt, QoS is used to represent the quality of service, with the following three values:
1) qos=0, at most once, the phenomenon of packet loss may occur. Use in situations where the requirement for real-time is not high. This level can be applied to scenarios such as ambient sensor data, and it doesn't matter if you lose a read record, because the next time you read the record, it will happen.
2 Qos=1, at least once, to ensure that the package will arrive at the destination, but a heavy package may appear.
3 qos=2, just once, to ensure that the package will arrive at the destination, and will not appear the phenomenon of heavy packets. This level can be used for scenarios such as billing systems where the loss or repetition of messages can lead to the cost of generating errors. Message format

The message header for each MQTT command message contains a fixed head. Some of these types of messages may also require a variable head and a payload (which can be understood as a message body). The fixed head of the MQTT message is only 2 bytes, which is why it is lighter than other protocols. BYTE1

Contains the message types and flags (including Dup,qos level and retain) fields, which we have already mentioned in the above. Now let's look at some other fields.

Message type identification count Description Reserved 0 Keep Connect 1 client to server connection request Connack 2 service-side response to connection request Publish 3 Release message Puback 4 response to release PU Brec 5 receives the release message (Guaranteed transmission part1) Pubrel 6 releases the release message (Guaranteed transmission part2) Pubcomp 7 completes the release message (guaranteed transmission PART3) Subscribe 8 Client Subscription Request Subback 9 Subscription Request Response Unsu Bscribe 10 Stop subscription request Unsubback 11 Stop subscription Request Response Pingreq Ping request (stay connected) Pingresp Ping Response Disconnect 14 client is disconnecting reserved 15 reservation

DUP
When the client or server attempts to PUBLISH, Pubrel, Subsribe, unsubscribe messages, the flag bit is set (that is, 1). This applies when the message's QoS flag value is greater than 0, at which point the message acknowledgement is required. When the DUP bit is placed, the variable header will contain a message ID.

The recipient of the message should treat the flag as a hint message that might have been received before the message, rather than relying on it for duplicate detection of the message.

RETAIN
The flag bit is used only for PUBLISH messages. When a client sends a PUBLISH message to the server, assuming that the message belongs to a Topica (topic), if the flag bit is set (1), the server should also keep this message after it publishes the message to all current Topica subscribers.

When a new subscriber appears Topica, the last Topica message should be sent to the Subscriber. Of course, if there is no maintenance message, then nothing is sent.

This feature is especially useful when the message Publisher sends a message based on the "Report by exception" method, where the message is often sent at a longer interval. This feature makes it possible for new subscribers to immediately receive a message that is previously maintained or last determined to be valid.

When the server receives a PUBLISH message for a topic, the server sends this PUBLISH message to clients that have previously subscribed to the topic, and the server sends the RETAIN flag of the message to 0 (that is, no bit) before the server receives the PUBLISH Whether the RETAIN flag is placed at the time of the message. This makes it possible to distinguish between the PUBLISH messages it receives from the server (the retain flag bit) or the instant receipt (retain flag not bit).

Keep messages should remain after restarting the server.

If the server receives a hold message that has a payload length of 0 or a recurring theme, the server can delete the hold message. BYTE2

This field represents the number of bytes of the current message's remaining content, including variable headers and payload data implementation of three types of QoS

Qos=0, and it guarantees that once the information is tried to deliver. A message is not answered by the receiving end and is not stored and sent by the sender. This is also called "the hair is discarded." And there will be the same guarantee under the TCP protocol.

When Qos=1, the message is sent at least 1 times, which guarantees that the information will be sent at least once to the recipient. But messages can also be sent two or more times. The sender will store the sent message until the sender receives an answer from the recipient's puback format. The Association of PUBLISH with Puback is done by comparing the packet identifier in the packet. If a puback response is not received at the timeout at a specific time, the sender resend the publish message. If the recipient receives a message with a QoS of 1, it will immediately process the message here, such as sending the packet to the receiving end of the subscription, and replying to the Puback package. The duplicate (DUP) flag is used to mark the situation where publish is redistributed. Only for internal use purposes, and when QoS is 1, it is not handled by broker or client. The recipient sends Puback messages, regardless of DUP flag.

When qos=2, it ensures that every message is received only once, and that he is the safest and slowest service level. If the receiving end receives a QoS publish message, he processes the message appropriately and sends a PUBREC packet to notify broker. The receiver saves the package packet identifier until he sends out a PUBCOMP packet. This is important because it avoids processing the same publish package two times. When the sender receives the PUBREC, it can discard the first publish, because it already knows the other end has received the message, he will save the Pubrec and reply Pubrel. When the receiving end receives the Pubrel, it can discard all the storage states of the packet and reply to Pubcomp. The same process is always the same when the sender receives the Pubcomp.

It is important to note here that the QoS stream is two different things at both the sender and the receiver, and of course the level of QoS at the sender and receiver can vary. Between the sender and broker, the sending end defines the QoS level. When broker sends a message to the receiving end, the receiver determines the level of QoS.

Here Mqtt some important points of knowledge are listed almost, there are some specific details of the need to be able to own Baidu under the mqtt of the document (with Chinese)