Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how the communication process of MQTT protocol is". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

MQTT connects to the server

After the network connection from the client to the server is established, the first message sent by the client to the server must be a CONNECT message

On a network connection, the client can only send the CONNECT message once. If the second CONNECT message appears, according to the protocol standard, the server will treat the second CONNECT message as a protocol violation and disconnect the client.

For a normal connection request, the server must generate a reply message, and if the session cannot be established, the server should report the corresponding error code in the reply message.

Mqtt007MQTT subscription topic

The client sends SUBSCRIBE messages to the server to create one or more subscriptions.

In the server, one or more topics concerned by the customer are recorded, and when the server receives PUBLISH messages for these topics, the application message is distributed to the matching client.

SUBSCRIBE messages support wildcards and specify a maximum QoS level for each subscription, and the server distributes application messages to clients based on this information.

SUBSCRIBE messages have fixed headers, variable headers and payloads.

When the server receives a SUBSCRIBE message sent by the client, it must send a SUBACK message response to the client, and the SUBACK message must have the same message identifier as the SUBSCRIBE message waiting for confirmation.

If the server receives an SUBSCRIBE message with the same topic filter as an existing subscription, the existing subscription must be completely replaced with a new subscription. The topic filter for the new subscription is the same as the previous subscription, but its maximum QOS value can be different. Any existing reserved messages that match this topic filter must be resent, but the publishing process cannot be interrupted.

Mqtt008

The payload of the SUBSCRIBE message contains a list of topic filters that represent the topics the client wants to subscribe to, and the list of topic filters in the SUBSCRIBE message payload must be an UTF-8 string.

The server should support topic filters that contain wildcards. If the server chooses not to support topic filters that contain wildcards, you must reject any subscription requests that contain wildcard filters.

Each filter is followed by a byte called a quality of service requirement (Requested QoS). It gives the maximum QoS level allowed by the server to send application messages to the client.

MQTT publishes messages

PUBLISH control message refers to sending an application message from the client to the server or the server to the client. In fact, the message distributed from the server to the subscriber also belongs to the PUBLISH control message.

Quality of service level QoS

The value of QoS indicates the quality of service level guarantee of application message distribution. In different quality of service levels, PUBLISH control messages are processed differently, and the receiver of PUBLISH messages (either server or client) must send corresponding reply messages according to the QoS level in PUBLISH messages.

The bit2-bit1 bit of the fixed header of the PUBLISH message indicates the quality of service level:

MQTT distributes application messages according to the quality of service (QoS) level defined here. When the server distributes application messages to multiple clients (subscribers), each client processes them independently. The quality of service for distributed messages may vary from the publisher to the recipient, depending on the level of service specified by the subscriber when subscribing to the topic. For publishers, the quality of service level is specified when the message is published.

PUBLISH control message of QoS0

The distribution of messages depends on the ability of the underlying network. The server does not send a response, and the publisher does not retry. It discards the message as soon as it sends out the message, which may or may not be delivered at all.

The publisher must send a PUBLISH message with QoS equal to 0 and DUP equal to 0.

When the server accepts the PUBLISH message, the message is distributed to subscribers to the topic (message).

PUBLISH control message of mqtt009QoS1

The quality of service ensures that the message is delivered at least once and may even be processed multiple times. The variable header of QoS1's PUBLISH message contains a message identifier, which requires PUBACK message confirmation.

Each time a new application message is sent, the publisher must assign an unused message identifier, store the message while publishing the message, and wait for a reply from the server until the corresponding PUBACK message is received from the receiver. The PUBLISH message sent must contain a message identifier and QoS equals 1 Magi DUP equals 0.

Once the publisher receives the PUBACK message from the server, the message identifier can be reused.

The PUBACK message that the receiver responds to must contain a message identifier, which comes from the received PUBLISH message. After sending a PUBACK message, the receiver must treat any inbound PUBLISH message that contains the same message identifier as a new message and ignore the value of its DUP flag.

PUBLISH control message of mqtt010QoS2

This is the highest level of quality of service, and there must be one and only one message to be processed, and message loss and repetition are unacceptable. There is an additional overhead to use this quality of service level.

QoS2 has a message identifier in its message variable header.

The recipient of QoS2's PUBLISH message uses a two-step acknowledgement process to acknowledge receipt.

The sender must assign an unused message identifier to the new application message to be sent. The PUBLISH message sent must contain a message identifier and the QoS of the message equals 2 and the QoS of the message equals 0.

After the message is sent, the message needs to be stored, and the PUBLISH message must be treated as unacknowledged until the corresponding PUBREC message is received from the receiver.

When the publisher receives the PUBREC message, it must send a PUBREL message. The PUBREL message must contain the same message identifier as the original PUBLISH message.

And the publisher must also treat the PUBREL message as unacknowledged until it receives the corresponding PUBCOMP message from the receiver. Once the corresponding PUBREL message is sent, the PUBLISH message cannot be retransmitted.

Therefore, as shown in the following figure, when a message is released, the message is stored immediately. After receiving the PUBREC message, the stored message must be discarded, and then the message identifier is stored. At the same time, the PUBREL message is sent out. Finally, the stored message identifier is discarded after receiving the PUBCOMP message.

Mqtt011

Of course, the corresponding distribution of messages is also more complex, it generally has two processing schemes, each of which ensures that the message is available and processed only once.

The PUBREC message that the recipient (in this case, the server) responds to must contain a message identifier, which comes from the received PUBLISH message.

After sending a PUBREC message, the receiver can distribute the message to the subscriber before receiving the corresponding PUBREL message, but the message identifier must be stored (scheme 1).

Of course, in this case, it can also store the message and not distribute the message to the subscriber until it receives the PUBREL message (scenario 2).

When it receives the PUBREL message, it must send the PUBCOMP message to the publisher, which must contain the same identifier as the PUBREL message.

At the same time, it can discard the stored message identifier (scheme 1) without having to distribute application messages to subscribers.

If you have not previously distributed the application message to the subscriber (scenario 2), you need to distribute the application message to the subscriber at this time, and then discard the message.

After the receiver sends the PUBCOMP message, the receiver must treat any subsequent PUBLISH message containing the same message identifier as a new publication.

Unsubscribe

The client sends a UNSUBSCRIBE message to the server to unsubscribe from the topic.

Bit 3 and bit 2 of the fixed header of the UNSUBSCRIBE message is reserved and must be set to 0, respectively. Otherwise, the server must consider any other value to be illegal and close the network connection. For a specific description, please see the agreement document.

The payload of the UNSUBSCRIBE message contains a list of topic filters that the client wants to unsubscribe. The topic filter in the UNSUBSCRIBE message must be a continuously packaged UTF-8 encoded string.

The payload of the UNSUBSCRIBE message must contain at least one list of topic filters, and the topic filter has been subscribed by the client, otherwise there is no subscription or unsubscription. If a UNSUBSCRIBE message without a payload violates the standard of the protocol, the server will not process it.

If the server deletes a subscription, it will no longer distribute messages for the topic to the client. And it must complete the distribution of any QoS1 and QoS2 messages that have started to be sent to the client to ensure the quality of service of the message.

The server must then send a UNSUBACK message in response to the client's UNSUBSCRIBE request. The UNSUBACK message must contain the same message identifier as the UNSUBSCRIBE message. Even if no topic subscriptions are deleted (topics unsubscribed by the client are not subscribed), the server must send a UNSUBACK response.

Mqtt012 disconnects

DISCONNECT message is the last control message sent by the client to the server. Indicates that the client is disconnected normally.

The fixed header reservation bits of DISCONNECT messages must all be 0.

After sending the DISCONNECT message, the client must close the network connection and cannot send any more control messages through that network connection.

The server must discard any unpublished testamentary messages associated with the current connection when it receives the DISCONNECT message. And when the client does not close the network connection, the server should take the initiative to close the network connection.

This is the end of the introduction of mqtt013 "how the communication process of MQTT protocol is". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.