MQTT 3.1.1, 6 new features worth upgrading

Objective

Previously read English articles or materials, after reading, summary or forget. This time select the interested Mqtt 3.1.1 to introduce the article information, the citation at the end of the text, as a practiced hand; not fully translated, to remove some of the advertising description, if infringement, please inform.

After four years of silence, the Qtt 3.1.1 specification was officially released on October 30, 2014, while the Mqtt 3.1.1 has become the OASIS (structured Information Standards Promotion organization) Open IoT Messaging Protocol standard (connection 1 connection 2), in other words mqtt 3.1.1 has been upgraded to the international Internet of things standards.

Just as HTTP paves the way for people to share information over the World Wide Web, MQTT can connect billions of of low-cost, embedded data-acquisition telemetry devices to the network.

Compared to the MQTT 3.1 (not yet the international standards for Internet of Things) specification, the Mqtt 3.1.1 goal is to eliminate ambiguity and to be as backward compatible as possible, in fact some of the new features required by the public are included in this version (more of the internet of things standards), so not only is a maintenance version, but also a huge improvement. In addition to the concept of clarification and the rewriting of stale specifications, there are some interesting changes that are noteworthy.

Session Representation flag (Present flag)

If a persistent session connection is established between a terminal and the server (assuming that the terminal is not using a "clean session" flag to clear the existing reply flag), a new "session Present" flag (Session token, A logical value of TRUE or false) appears in Connack, indicating that the MQTT server already has the current client's last connection session information, such as the subject of the subscription, queued information, and other information.

The session representation flag if true, the client can reduce the one-time send subscription subscrible interaction step to facilitate more efficient data communication; to false, the client needs to send the subscription subscrible message again, not to be skipped.

New subscription Failure Code feedback

Before Mqtt 3.1.1, a terminal connection cannot know whether the subscription subject it sends is accepted by the MQTT server. This new feature is better suited for fine-grained permissions on MQTT topic management; If there is no authorization, the server attaches the error code (0x80) to the Suback, and the client can know that the subscription failed.

Mqtt Anonymous Client

Need support for temporary or anonymous? The client simply needs to empty (0 length) the client identifier (identifier) when it sends connect, and the MQTT server generates a random, unique client token for such requests. However, this requires the client to set the clean session flag to 1, otherwise the server will return a connack that contains 0x02 (Identifier rejected) code and close the connection.

The MQTT server program can be treated differently for clients that can be used to send messages to the terminal program (which does not require a maintenance reply state).

Quick Release No wait

This is a particularly useful feature, the client can send connect, can not wait for the MQTT server to return the Connack, as soon as necessary to send publish, subscrible, Disconneect and other messages, to avoid client resource waiting. This feature also applies to burst mode (burst-mode) client requirements and only concerns that the data should be sent as soon as possible, rather than worrying about whether a long connection needs to be maintained.

This requires the MQTT server implementation to check whether the client has permission to publish to these topics before distributing the message.

The client identifier can grow a bit longer

The MQTT 3.1 limit for client identifier is 23 bytes, which can be inconvenient in the real world, and legacy systems may use UUID as the client identifier, so the server side needs to do some map mapping between the two. The upper limit for MQTT 3.1.1 is 65,535 bytes, which, after all, is an industry standard that requires a large number of legacy devices and infrastructure to be compatible.

Other minor changes

1. Connect message variable Header protocol name MQISDP is changed to MQTT for more accurate semantics
2. All strings explicitly specify the use of UTF-8 encoding, including client-side identifiers (Identifier)
3. Connect message Variable Header protocol version number, changed from 0x03 to 0x04 QoS 0 type publish message The DUP token must be set to 0
4. The MQTT over WebSocket is defined, and the Internet Address Encoding Distribution Authority (Internet Assigned Numbers Authority) assigns an identifier of MQTT. Although WebSocket is not mentioned throughout the Mqtt 3.1 specification, the second binary attribute can be easily transmitted over the WebSocket channel.

Terminology changes

• Mqtt Server with MQTT broker (MQTT Broker is now MQTT server)
• Message ID, package ID (Message ID is now Packet ID)
• Message type, package type (message type is now Packet type)
• Theme path, subject name (Subscribe and unsubscribe take Topic Paths, rather than Topic names)
• Previously in the fixed head, now within the package type (Flags in the fixed header is current specific to the packet type
• 0 bytes reserved information needs to be cleared (A zero byte retained message must not being stored as A retained message on the Server)

Summary

The current MQTT 3.1.1 has been supported in many active open source projects/commercial products. such as Eclipse Paho,mosquitto,jboss a-mq 6.1, Apache ActiveMQ 5.10-snapshot,apache Camel 2.13.0,hivemq.

About Eclipse Paho:

1. The Eclipse Paho 1.0 supports the Mqtt 3.1.1 and MQTT 3.1 specifications
2. Eclipse Paho 0.9 only supports the MQTT 3.1 specification

Clients that include Mqtt 3.1.1 and MQTT 3.1 can be mixed, can coexist under the same MQTT server, have no major modifications at the basic message transport level, and the same publish messages can flow freely through the MQTT client, which requires server-side encoding support.

Existing MQTT 3.1 clients can be upgraded in a hurry, but after the upgrade they can benefit a lot from the new features.

Original

Http://www.blogjava.net/yongboy/archive/2014/12/16/421460.html

MQTT 3.1.1, 6 new features worth upgrading