MQTT v5.0 now an official OASIS standard

OASIS has now published the official MQTT v5.0 standard – a huge leap forward in refinement and capability for the messaging protocol that already powers the Internet of Things (IoT). Based on the earlier v3.1.1 standard, it has significant updates whilst minimising incompatibilities with existing versions.

The highlights of the new version include:

• Better Error Reporting – in particular, a reason code has been added to responses for publications (PUBACK/PUBREC). MQTT originated with use cases like sensors along an oil pipeline – if their publications fail to be transmitted then the sensor will take no action. However the use cases for MQTT are now much broader and an app on a phone may well want to warn the user if data is not being transmitted successfully. Return codes are now present on all acknowledgements (along with optional reason strings that contain human readable error diagnostics).
• Shared Subscriptions – If the message rate on a subscription is high, shared subscriptions can be used to load balance the messages across a number of receiving clients.
• Message Properties – Metadata in the header of a message. These are used to implement the other features in this list but also allow user defined properties e.g. to assist in message encryption by telling the receiver which key to use to decrypt the message contents
• Message Expiry – An option to discard messages if they cannot be delivered within a user-defined period of time.
• Session Expiry – If a client does not connect within a user defined period of time, state (e.g. subscriptions and buffered messages) can be discarded without needing to be cleaned up.
• Topic Alias – Allows topic strings in messages to be replaced with a single number, reducing the number of bytes that need to be transmitted if a publisher repeatedly uses the same topics.
• Will Delay – Allows a message to be published if a client is disconnected for more than a user defined period of time. Allowing notifications about outages of important client applications without being swamped by false positives.
• Allowed Function Discovery – At the start of a connection, limits like the maximum packet size and number of (QoS>0) messages inflight can be transmitted to inform the client what it is allowed to do.

The complete list of new features is in Appendix C of the standard.

Many clients and servers already have support for the new standard but as it is less than a month old, many implementations are still working on their support.

Source : http://mqtt.org/

Recommended: MQTT 5 | Overview | What’s New | MQTT Features | MQTT 5.0

You may like also:

• How To Create Secure MQTT Broker
• MQTT Servers/Brokers
• MQTT Products (that use MQTT)
• MQTT Public Brokers List
• IoT Data Protocols
• Setting up Authentication in Mosquitto MQTT Broker
• VerneMQ – Clustering MQTT for high availability and scalability
• How To Install VerneMQ on UbunTu, RHEL, Docker, Debian and Cent OS