MQTT Version 5 Status

The MQTT Version 5 implementation is currently in development. This page documents the current implementation status as well as how to access our latest develoment branch.

Current status

As this is a work in progress, not everything is implemented and there are a number of known issues. If you'd like to contribute we'd love your pull requests or feedback!

Currently supported features are:

  • All MQTTv5 frames are implemented.
  • MQTTv5 enhanced authentication and reauthentication.
  • Publishes with payload format indicator, response topic, correlation data, user properties and content type.
  • Message expiration.
  • Delayed last will and testament.
  • Retained messages.
  • Shared subscriptions.
  • Session expiration interval.
  • Request/response using 'response topic' and 'correlation data' properties.
  • Client to broker topic aliases.
  • Broker to client topic aliases.
  • Receive maximum flow control.
  • Subscription flags Retain as Published, No Local, and Retain Handling.
  • Subscriber Ids.
  • MQTTv5 and older prototocols can be enabled at the same time (set allowed_protocol_versions=3,4,5 on the listener to enable respectively MQTT v3.1, 3.1.1 and 5.0).

Currently known issues for MQTTv5 are:

  • Tracing (vmq-admin trace) doesn't yet support tracing MQTTv5 sessions.
  • The plugin hooks for MQTTv5 sessions doesn't yet handle the new MQTTv5 features.
  • Bridge plugin does not yet support MQTTv5.
  • Server and client maximum packet size enforcement is not yet implemented.

Current limitations/open questions:

  • Currently when using allow_multiple_sessions=on:
    • If using delayed last will and testament it is only sent for the last connected client.
    • The session expiration used is the one from the last connected client or the last client which send a new session expiration value when disconnecting.
  • If using allow_multiple_sessions=on, should it be allowed to mix MQTTv5 and MQTTv4 sessions? What are the pros and cons?

Unknown issues:

We are sure there are many. Please play with this and let us know if something doesn't look right! We'd love to get your feedback!

Trying it out

On this branch MQTTv5 is enabled by default and all MQTTv5 actions are allowed as a plugin called vmq_allow_all_v5 is enabled which implements the auth_on_register_v1, auth_on_subscribe_v1 and auth_on_publish_v1, all of them simply return ok allowing the actions.

So to get started, simply create a clone of this repository and switch to this branch and then build VerneMQ using make rel as usual. VerneMQ can then be started by running _build/default/rel/vernemq/bin/vernemq console and you can now connect MQTTv5 clients to the listener running on localhost:1883.

Topic Aliases

To try out the topic alias feature you have to enable it either in vernemq.conf or via vmq-admin set command.

topic_alias_max_client=10 enables that the client can use up to 10 topic aliases when publishing messages to the broker. topic_alias_max_broker=10 enables that the broker can use up to 10 topic aliases when delivering messages to the client.

Both settings are disabled by default.

Reporting issues

As this is a work in progress we really would appreciate your feedback! To report an issue or a question, please open an issue on github and prefix the issue title with MQTTv5:. You're also more than welcome to reach out to us on slack or get in touch with us via our contact form.

MQTTv5 plugins vs MQTTv4 plugins

MQTTv5 plugins use a different set of hooks as MQTTv5 has more features than MQTTv4. The hooks in MQTTv5 has the same names as in MQTTv4, but are post-fixed with _v1 (hook version 1), so for example in MQTTv5 auth_on_register_v1 corresponds to the MQTTv4 hook auth_on_register. MQTTv5 also introduces a new on_auth_v1 hook to support enhanced (re-)authentication.

Don't forget to subscribe to our Newsletter!