The message flow of the MQTT protocol note

Objective

The previous note has gone through all the message types and tried to decipher it from the point of view of the message flow.

Network failure

In any network environment, there will be a connection failure, such as leaving the company door at the moment without a WiFi signal. But the other end of the persistent connection-the server may not immediately know that the other side is disconnected. Similar to the network anomaly, it is possible that the message is sent in the process of occurrence, the message sent out, is lost.

The MQTT protocol assumes that the client and server-side stability generally, the communication pipeline is not reliable, once the client network disconnects, the situation is very serious, it is difficult to restore the original.

But do not forget that many clients will have permanent storage device support, such as Flash ROM, memory card, etc., in case of abnormal communication can be used to save critical data or status information.

In short, the abnormal network situation is very complex, can only be handled with care.

Message re-send policy

In the case of QoS > 0 , PUBLISH, Pubrel, SUBSCRIBE, unsubscribe, and other types of messages will need to wait for a response message after the sender has sent it, and the sender may need to retry if it is not received within a specified time period. The message that is being re-sent requires the DUP tag to be set to 1.

The timeout for waiting for a response should be counted after the message has been successfully sent, and the wait timeout should be configurable so that the next retry is properly increased. For example, the first retry time-out is 10 seconds, the next time may be 20 seconds, and another retry may be 60 seconds. Of course, there is also a retry limit.

In another case, the client reconnected, but did not set the clean session tag in the mutable header, but both sides (client and server side) should retry the previously unsent dynamic message (in-flight messages). The client is not forced to send unacknowledged messages, but the server side needs to resend those messages that are not acknowledged.

QoS level-Determined message flow

QoS level is the abbreviation for quality of service levels, translated into Chinese, service quality grade.

The MQTT 3.1 protocol in the "4.1 quality of Service levels and Flows" section discusses only the client-to-server publishing process, which is not complete. Because determining the message arrival rate, can improve the quality of delivery, should be the server to publish publish messages to subscribers this message flow direction.

QoS Level 0

Send at most once and discard. There is no confirmation message and I do not know if the other party received it.

Client	Message and Direction	Server
QoS = 0	PUBLISH ---------->	Action: Publish message to subscribers then forget Reception: <=1

The message is not important, it doesn't matter if it's lost.

At the network level, the transmission pressure is small.

QoS Level 1

All QoS Level 1 is appended with a 16-bit message ID in the variable header.

Subscribe and UNSUBSCRIBE messages use QoS Level 1.

For message Publishing,Qos Level 1means that messages are transmitted at least once.

If the sender does not receive the Puback message for a period of time, the sender needs to open the dub labeled 1 and resend the publish message. As a result, the receiving party may receive two publish messages. To publish messages to the server for a client message flow:

Client	Message and Direction	Server
QoS = 1 DUP = 0 Message ID = x Action: Store message	PUBLISH ---------->	Actions: Store message Publish Message to Subscribers Delete message Reception: >=1
Action: Discard message	Puback <----------	Message ID = x

Message flows to Subscribers for server publishing:

Server	Message and Direction	Subscriber
QoS = 1 DUP = 0 Message ID = x	PUBLISH ---------->	Actions: Store message Make message available Reception: >=1
	Puback <----------	Message ID = x

If the Publisher (client/server) receives no Puback messages due to various exceptions, it will resend the publish message again, setting the DUP flag to 1. The recipient takes the server as an example, which may cause the server to receive duplicate messages, follow the process, the broker (server) publishes the message to the Subscriber (which causes the Subscriber to receive duplicate messages), and then sends a puback acknowledgment message to the publisher.

At the operational level, it may be possible to compensate for the deficiencies of the MQTT protocol: The message ID of the retry must be consistent the receiver must determine if the current received message ID has been accepted

But just as not to be completely sure, the message must have arrived.

QoS Level 2

Only appears in the Publish type message, requiring the message ID to be appended to the variable header.

The level is higher, the communication pressure is slightly larger, but ensures that only the transmission is received once.

First look at the protocol flowchart, Client-to-server direction, there will be a general impression:

Client	Message and Direction	Server
QoS = 2 DUP = 0 Message ID = x Action: Store message	PUBLISH ---------->	Action (a) Store message Or Actions (b): Store message ID Publish Message to Subscribers
	Pubrec <----------	Message ID = x
Message ID = x	Pubrel ---------->	Actions (a): Publish Message to Subscribers Delete message Or Action (b): Delete message ID
Action: Discard message	Pubcomp <----------	Message ID = x

Server-Subscriber:

Server	Message and Direction	Subscriber
QoS = 2 DUP = 0 Message ID = x	PUBLISH ---------->	Action: Store message
	Pubrec <----------	Message ID = x
Message ID = x	Pubrel ---------->	Actions: Make message available
	Pubcomp <----------	Message ID = x

Scenarios A and B taken by the server side include when the message is valid and when the message is processed. Two option two select one, the server side decides. However, regardless of the mode of death, is in the QoS Level 2 protocol category, not affected. If a party does not receive a corresponding confirmation message, it will retry from the last message that needs confirmation so that the entire (QoS Level 2) process is opened.

Message Order

Message order is affected by many factors, but for server programs, you must ensure that each phase of the messaging process is consistent with the order in which it starts. For example, in a message flow defined in QoS Level 2, the Pubrel stream must be sent in the same order as the publish stream:

Client	Message and Direction	Server
	PUBLISH 1 ----------> PUBLISH 2 ----------> PUBLISH 3 ---------->
	Pubrec 1 <---------- Pubrec 2 <----------
	Pubrel 1 ---------->
	Pubrec 3 <----------
	Pubrel 2 ---------->
	Pubcomp 1 <----------
	Pubrel 3 ---------->
	Pubcomp 2 <---------- Pubcomp 3 <----------

The number of mobile messages (in-flight messages) allows for a guaranteed effect:

• In the flow message (in-flight) window 1, each delivery flow is completed before the next stream begins. This guarantees that messages are delivered in the order in which they are submitted
• In a window with a flow message (in-flight) greater than 1, the order of messages is guaranteed only within the QoS level

Persistence of messages

In the MQTT protocol, the publish message is pinned to the head retain tag, and only 1 requires the server to persist this message unless the new publish is overwritten.

For a persistent, up-to-date publish message, the server is sent not only to the current subscriber, but also to the new Subscriber, subscriber, who needs to subscribe to the topic name for this message, to be pushed immediately.

Tip：新来乍到的订阅者，只会取出最新的一个RETAIN flag = 1的消息推送，不是所有。

encoding/decoding of message flows

In the MQTT protocol, 14 types of messages that are currently defined interact with the data between the client and server side. If you are building an MQTT server in the Java language, you can choose Netty as the basis.

In Netty, the entry and outflow of data represents a complete interaction. Both incoming and outgoing data (server as an example) can be viewed as a byte stream. If you abstract each type of message into a specific object, it is not difficult to deal with it.

The client-side server, which enters the byte stream, reads bytes/units, and can be reverted to a specific message object (the decoding process).

The message object to be sent to the client, converted (encoded) into a byte stream, and then transferred by the TCP channel to the receiver.

Summary

A number of reading notes for the MQTT 3.1 protocol were recorded on and off, with a focus on analysis in the sense that the agreement was not clear enough or that I did not understand. It is also easy to return to the back of the story to flip through, not so fast forgetting.

Original http://www.blogjava.net/yongboy/archive/2014/02/15/409893.html

The message flow of the MQTT protocol note