Description of the function of MQTT-SN protocol rollover

Objective

Immediately above, this is the third article, mainly on the MQTT-SN 1.2 protocol for the overall function of the description.

Well, this part can be compared with the MQTT protocol.

Broadcast and discovery of gateways

The gateway can broadcast advertise messages to all clients periodically in the wireless personal area network Wpns only after a successful connection to the MQTT server, allowing the client to passively know the presence of the gateway.

Under the same network, multiple gateways with different IDs can run concurrently, but the client connects to a specific gateway depending on the signal strength, whenever only one gateway can be connected.

The client can maintain a list of available gateways (including the gateway address), and after receiving the advertise and Gwinfo messages that contain the new gateway ID, the list needs to add a new gateway element in.

Advertise broadcast messages contain the next broadcast interval length duration attribute, in seconds, set to variable t_adv, should be as large as possible with 15 minutes (900 seconds), frequency reduction is to avoid slow congestion of the personal area network.

For receiving advertise message frequency, the processing ability of the client can be used to monitor whether the gateway is available. Eg: the client does not receive a gateway advertise broadcast message for successive N_ADV times, it can be considered dead and unavailable and removed from the list of maintained gateways. Similarly, as an alternate gateway, the primary gateway is considered to be dead and can be activated at this time.

The gateway sends broadcast message advertise for a long interval, which is detrimental to the client that caused the new join, but the client can send the SEARCHGW broadcast message directly to query the gateway. A large number of new devices can cause a broadcast storm to cause network congestion, and each newly added client needs to obtain a random delay send value (0-TSEARCHGW) before sending the SEARCHGW broadcast message, and if it receives SEARCHGW broadcast messages from other clients during the delay waiting to be sent , it cancels its own SEARCHGW broadcast message and waits for the gateway to Gwinfo message notification.

SEARCHGW Message Properties Radius broadcast radius, recorded as variable rb,1 hop (1 hop) is generally available in MQTT-SN clients under general dense deployment.

When the gateway receives the SEARCHGW, it immediately responds with the GWINFO message containing its ID. After the client receives SEARCHGW, if there is a need to delay the sending of the SEARCHGW will be canceled, if you maintain a list of multiple available gateways, waiting for t_gwinfo time without receiving gwinfo messages, will be taken from the list of a gateway information assembled into a GWINFO message and broadcast out. This requires that the client has been running for a long while and maintains a list of multiple available gateways.

The Gwinfo and SEARCHGW contain the same radius radius attribute values, which requires the underlying network to decide whether it needs to be transferred to other types of networks when it is transmitted.

If a response is not received, the SEARCHGW message may be retransmitted. Two consecutive SEARCHGW message retransmission intervals should be exponentially increased to avoid too dense transmission.

Connection Establishment for Client

Regardless of the transport protocol, TCP or UDP, the client needs to establish a connection and maintain a heartbeat, maintaining a continuous line of bidirectional channels both logically and on the server side. The following diagram illustrates the process by which a client establishes a connection, and sets the client's will property to be true in the flag bit field in the Connect message, and then has the request process for a testamentary subject/message.

In many cases, connecting to connect does not require a testamentary support, the gateway will return the Connack message directly, but the gateway will be congested or does not support some connet features, Connack contains the return Code field ReturnCode contains the rejection code, Ask the client to check if the connection is successful and treat differently. Like what:

CONNACK消息返回状态码为0x01（Rejected: congestion，因拥塞被拒绝），客户端需要在T_WAIT时间间隔后进行重试。

Clean up.

After a disconnected client is disconnected, information such as previous subscriptions will persist at the gateway if the session cleanup (clean session) ID was not set previously in Connect. The "Clean Session" logo in MQTT,MQTT-SN is extended to the Wills feature. In the Connect message, the cleansession and will combinations have the following effects:

• cleansession=true, Will=true: The gateway will delete all previous subscriptions and wills, and a new testamentary theme/message is about to be re-processed later
• cleansession=true, Will=false: The gateway will delete all previous subscriptions and wills, returning Connack messages
• Cleansession=false, Will=true: The gateway will continue to hold all of the previous subscriptions, and the new testamentary theme/message is about to be re-processed later
• Cleansession=false, Will=false: The gateway will continue to hold all of the previously corresponding data for subscriptions and wills, and return connack messages

Update the Wills Process

• Conneection in the flag will set whether you need to update the Wills topic/message
• Empty willtopic (two bytes) message will cause the gateway to delete the corresponding testamentary data
• WILLTOPICUPD/WILLMSGUPD can update/modify probate themes, wills messages
• Blank willtopicupd (two bytes) message means that the request net empties the data for the existing wills

Subject Registration Process

Limited bandwidth and a small message payload limited by wireless sensor networks, the publish message cannot contain the full subject name topic name. This requires the registration process between the client and the gateway to get the topic ID (16-bit natural number) corresponding to the subject name, and then plug in the TopicID attribute of the publish message.

The client sends a register message, and the gateway returns a Regack message that contains the Returencode attribute that determines whether the registration is successful or not:

• ReturnCode = "Accepted", TopicID can be very enjoyable to use in a later publish message
• ReturnCode = "Rejected:congestion", the client needs to wait a while (t_wait means, greater than 5 minutes) to re-register again
• ReturnCode = "Rejected:invalid topic Id/not supported", the client needs to be slightly adjusted and re-registered again

Any time, only a register message can be executed, there is no completion of the registration process, need to wait.

Gateway-to-client direction, the gateway sends a register message to the notification client to specify that TopicID corresponds to a topic so that subsequent send publish messages are used. If the client uses the wildcard character (#/+) when subscribing to the SUBSCRIBE message, then the matching topic name will be notified to one by one. It is therefore not recommended to use wildcards, which are less efficient.

Client publishing process

Once the client obtains the topic name corresponding to the topic ID, it can send the publish message directly. This is in contrast to the MQTT protocol, where topic name is replaced with the topic Id in the Publish message, in addition to the ReturnCode:

• ReturnCode = "Rejected:congestion", the client needs to wait a while (>5 minutes) and retry again
• ReturnCode = "Rejected:invalid topic ID", the client needs to re-register topic name to get the topic ID and then republish again

QoS 1 and QoS 2 at any one time, you must wait for the publish message to complete before you can perform the following publish message publishing process.

Predefined topic ID and a two-character topic name

The predefined topic ID has been assigned the corresponding topic name in advance, requiring the client and gateway to support at the code level, omitting the intermediate registration process, which can be publish immediately after the connection is established. However, this requires setting the Topicidtype value to 0b01 (0B10 represents a short topic name of two bytes length) in the Publish Flag flags field. Although you can quickly send a publish message, the client wants to subscribe to a predefined topic ID, receive the corresponding publish message, and send a subscrible message request to subscribe. If you specify a predefined topic ID randomly, you will receive an exception returncode= "Rejection:invalid topic ID".

The predefined short topic name is only a two character long string (also two bytes), a topic ID of two bytes for a natural number (0-65535), both use the scene consistent, both need to set the Topicidtype specific value at the flag bit flags, 0B01 indicates that a predefined topic ID,0B10 represents a short topic name of two bytes long and needs to be distinguished.

Publish corresponding QoS-1 value

This does not support any features other than a very simple client implementation that supports only publish QoS-1. It does not care whether the connection is established, nor is it registered or subscribed to, it sends the publish message directly according to the gateway address that has been cured to the code, does not care whether the gateway address is correct, whether the gateway is alive, and whether the message was sent successfully.

The following publish property values depend on the QoS-1 situation:

• QoS flag, set to 0B11
• Topicidtype Flag, possibly (pre-defined topic ID) 0B01 may also be (short topic name) 0B10
• TopicID field, predefined topic ID or Short topic name
• Data field, need to send, no change

Client subscriptions and Unsubscribe

The client is interested in a topic, can initiate the subscrible process, carries the subject name (topic ID) of interest, and the server typically returns a Suback message containing the specified subject ID (topic ID). The subscription failed and can be learned from the Puback ReturnCode:

• ReturnCode = "Rejected:congestion", the client needs to wait for a period of time t_wait (>5 minutes) and retry again

One case is that the Subscrible subscription topic contains wildcards, and the gateway's processing is simple, and the topic ID returned in Suback is 0x0000. Later, the gateway sends a register message to the client to go through the registration process, notifying the wildcard to match the topic ID value to the subject.

The subscrible message from the client supports the predefined topic ID as well as the short topic name, which is similar to the publish message.

Unsubscribe is simple, the client sends a unsubscrible message, and the gateway returns a Unsuback message.

But at the same time, the client only allows to process subscription subscrible or unsubscribe unsubscrible in serialization order, the next operation depends on the last operation being completely successful.

Gateway Publishing Process

The server publishing process is similar to the client, which needs to detect if its subject has been pre-registered with the client before publishing, and if it is not necessary to send the subject and the specified topic ID into the register message to the client for the registration process, then wait for the client to process the result regack. The registration is passed before the publish message can be sent properly.

The gateway needs to ensure that the subject of the register and the content load of the publish message are not too long to exceed the current Network load limit (for example, no more than 60 bytes in the ZigBee environment), and cancel the registration/release process.

When the Gateway publishes the publish message, the client detects an unknown Topic ID, encapsulates the reject justification to puback, and the gateway encounters a returncode= "Rejected:invalid Topic ID" illegal Topic ID that needs to be considered for deletion or re-registration.

The client may reject its registration, may not allow the publish message, the gateway as the silent processing on the good, failure will fail, do not need to inform others.

The client publishing process is similar in that it needs to register the subject before publishing to obtain the specified topic ID, and after committing the publish message, it is also necessary to check whether the ReturnCode field contained in Puback is accepted or rejected, and the client needs to be in the T_ Retry after the wait time.

The client's publication must be serial, and the next message that needs to be sent to the publish waits for the previous send to be successfully accepted by the gateway before it can be processed.

Heartbeat KeepAlive Process

Typically a gateway-to-client, gateway-to-client is not a problem. But requires pingreq-PINGRESP must be a single-hour cycle, Pingreq sender can not also be PINGRESP sender, so not only disorderly process, also wasted network resources. Well, two-way cross-hair is not allowed.

The client connects to the next replaceable gateway by monitoring the health of the connected gateway based on the heartbeat mechanism and not receiving the PINGRESP message from the gateway many times in a row. Because the client's connection and heartbeat are not synchronized with other client state properties, this can cause a problem, and if a large number of clients flood and connect to a gateway at the same time, the gateway may be washed out without warning. This requires the gateway to have the bulk of the connection processing power, concurrency feature enhancement.

Client disconnection Process

After the client actively sends a disconnect message informing the gateway that a disconnection is required, a new session connection can be restarted if there is a need to exchange information. After disconnect the message, the gateway does not clean up the existing subscription and will data unless the cleansession session cleanup ID is set to true in the previous connect message. After the gateway receives the disconnect message, it returns a disconnect message as a response.

In one case, the client suddenly receives a disconnect message from the gateway, which may be an exception to the gateway itself, or the gateway cannot locate the client's message attribution (the client's message and the client cannot be linked together). At this point the client needs to send a connect message to rebuild the session connection to the gateway.

Client retransmission Process

The message for the client-side gateway is unicast, depending on the unicast address of the connected gateway held by the client.

After the client sends a message, it needs to start a retry timer tretry and a retry counter nretry to monitor the gateway message response. The timer will be canceled by the client after receiving the message from the gateway within the specified time, if it is not received on time, it will trigger the timer to carry out the message re-sending process, and after successive nretry, the client will cancel the current process directly, judging that the current gateway is disconnected and need to connect to another available gateway. If the other network Sekiya is a connection failure, it attempts to reconnect the previous gateway.

If the retry counter value is exceeded in hibernation, the client goes directly to hibernation.

Client Hibernation support policy

The client here refers to the battery-powered electronic devices, you have to understand a fact, save battery resources is how important, power saving is the key, no electricity has no play. When not in the active state, in order to save power needs to go to sleep/hibernation, when there is data need to receive or send to wake up. The gateway needs to track the sleep state of the device and support the caching of messages that need to be sent to the dormant device, which is sent each time the device wakes up.

Here is the client's state transition diagram, which clearly describes the interactions between the various states:

The client has five states: active (Active), Hibernate (Asleep), Wake (Awake), wire break (disconnected), Lost (lost), and can only be one at a time.

The gateway needs to oversee the status of the client, starting with the live-time field in the Connect message (keep alive), which will activate the corresponding testamentary feature if it is not received from the client message for a long time than the lifetime of the network, and the gateway considers the client to be in a lost state (lost).

The client sends a disconnect message but does not have a duration sleep duration field, and the gateway will be in a disconnected state without time supervision. Once the duration sleep Duration field is included, indicating that the client needs to hibernate for a period of time, the gateway client is converted to hibernation, and the sleep duration is duration defined in the value. Beyond this time of sleep, if the gateway does not receive any messages sent by the client, then the client will be converted to a lost state, if the testamentary characteristics are set, then the testamentary characteristics will take effect. Messages that need to be sent during client hibernation will be cached by the gateway.

The flowchart will be more visually descriptive of the process during sleep:

There is no doubt that the gateway can use a sleep timer to maintain the client's sleep state, and so on, the sleep timer will be stopped when the gateway receives a PINGREQ message sent by the client, the gateway retrieves the presence of the cached publish message from the customer ID contained in the PINGREQ message. If any, they will be sent to the client in sequence. After all the corresponding cached messages have been sent, a PINGRESP message is sent with it. If no message is cached, the gateway returns a PINGRESP message directly. The gateway restarts the sleep timer, and the client state that the gateway maintains is converted to hibernation, and after the client receives the PINGRESP message, it will turn directly to hibernation, saving power.

The client processes the message in a wake-up state, adheres to the "client retransmission process" behavior, and goes to sleep once the retry counter limit is reached.

When a client transitions from hibernation to wake state to check if the gateway is caching messages for it, a pingreq message needs to be sent to the gateway; from hibernation/wake state to Active state, a connect message is sent to inform the gateway , a disconnect (no sleep-time-long field duration) message is required when converting to a disconnected state, and a disconnect message (with a new duration time value) is required to notify the gateway when a redefined sleep duration is needed.

Summary

Functional description is finished, basically MQTT-SN protocol introduction is nearing the end, the last chapter is a short description of the implementation.

Original http://www.blogjava.net/yongboy/archive/2015/01/09/422156.html

Description of the function of MQTT-SN protocol rollover