MQTT 5 Features & Hidden Gems: Introduction to MQTT 5

Written by The HiveMQ Team

Category: MQTT MQTT5 Features and Hidden Gems

Published: December 11, 2017

Introduction to MQTT 5

Welcome to our brand new blog post series MQTT 5 - Features and Hidden Gems. Without doubt, the MQTT protocol is the most popular and best received Internet of Things protocol as of today (see the Google Trends Chart below), supporting large scale use cases ranging from Connected Cars, Manufacturing Systems, Logistics, Military Use Cases to Enterprise Chat Applications, Mobile Apps and connecting constrained IoT devices. Of course, with huge amounts of production deployments, the wish list for future versions of the MQTT protocol grew bigger and bigger.

MQTT 5 is by far the most extensive and most feature-rich update to the MQTT protocol specification ever. We are going to explore all hidden gems and protocol features with use case discussion and useful background information - one blog post at a time.

Be sure to read the MQTT Essentials Blog Post series first before diving into our new MQTT 5 series. To get the most out of the new blog posts, it’s important to have a basic understanding of the MQTT 3.1.1 protocol as we are going to highlight key changes as well as all improvements.

The revival of the MQTT Monday

Some of our longtime readers will remember the MQTT Monday introduced by our older blog post series: MQTT Essentials, MQTT Security Fundamentals, MQTT Client Library Encyclopedia and the MQTT Toolbox.

If you liked the format, we have fantastic news for you: We’ll release a new MQTT 5 blog post, each one highlighting a specific feature, key change or fun trivia regarding MQTT 5, every Monday. Just subscribe to the weekly newsletter below if you want us to send the articles straight to your inbox.

MQTT History

Let’s have a look at the history of MQTT first: Although the MQTT protocol was invented in 1999, its triumphant march began years later, in 2010, when it was released to the public under a royalty free license as protocol version 3.1. Four years after the initial public release, MQTT 3.1.1 was released as an OASIS and ISO standard in 2014. The 3.1.1 version included predominantly clarifications and minor protocol improvements. At the time of writing (December 2017), the MQTT 5 specification closed its second public review phase at OASIS and is expected to be released in a final version in early 2018.

MQTT 5 Design Goals

The Technical Committee (TC) responsible for specifying and standardizing MQTT at OASIS mastered a balancing act: How to advance the protocol in a way that the protocol would stay as lightweight and easy to use as it was in 3.1.1 and still add features demanded by longtime users without adding unnecessary complexity and without sacrificing performance and scalability.

The goals for the MQTT 5 specification were articulated by the OASIS TC as follows:

  • Enhancement for scalability and large scale systems
  • Improved error reporting
  • Formalize common patterns including capability discovery and request response
  • Extensibility mechanisms including user properties
  • Performance improvements and support for small clients

With these goals in mind, the TC managed to specify some extremely useful new features that came from requirements of MQTT 3.1.1 production deployments. The TC also added features back to the standard that sophisticated broker implementations like HiveMQ already provided for MQTT 3.1.1. Popular features like Shared Subscriptions and Time to Live for Messages and Client Sessions are now part of the standard.

An interesting goal of the new specification is the “Enhancement for scalability and large scale systems”. Some new MQTT behaviors allow simple broker implementations to enhance scalability. _Enterprise MQTT Brokers like HiveMQ showed that MQTT 3.1.1 is one of the most scalable stateful IoT protocols in the world by benchmarking 10.000.000 MQTT simultaneous connections on cloud infrastructure for a single MQTT broker cluster. The new version of the protocol is designed to make it even easier to scale to immense amounts of concurrent connected clients for brokers.

Trivia: Why Protocol Version 5?

Some readers might ask: Why is the successor of MQTT 3.1.1 called “MQTT 5”?

The answer is surprisingly simple: The MQTT protocol defines a fixed header in the CONNECT packet. This header contains a single byte value for the protocol version.

If you would inspect the CONNECT packet on the wire, you would make an interesting observation: While MQTT 3.1 had the value ‘3’ as protocol version, MQTT 3.1.1 used the value ‘4’. In order to streamline the protocol version on the wire and the official protocol version name, both now use the number 5.

Is it time to upgrade yet?

You might wonder: Should I upgrade yet?

Next week’s blog post will provide a detailed look at this question. If you’d like to receive the next and all upcoming articles directly in your inbox, just use the newsletter subscribe form below.

We hope you enjoyed this first part of the new series. Let us know what you think and what you would like to see in future blog posts in the comment section below.

You like the MQTT 5 Series? Then sign up for our newsletter and get notified on all new posts as soon as they are available. If you prefer RSS, you can subscribe to our RSS feed here.

Have an awesome week, The HiveMQ Team

About The HiveMQ Team

We love writing about MQTT, IoT protocols and architecture in general. Our experts are here to help, so reach out to us if we can help!
Contact us
<  HiveMQ 3.2.8 Released   |   MQTT 5: Is it time to upgrade to MQTT 5 yet?   >