Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MQTT version 5.0 support #308

icraggs opened this Issue Jul 26, 2017 · 5 comments


None yet
3 participants
Copy link

icraggs commented Jul 26, 2017

The MQTT version 5.0 specification is nearing completion, with the availability of working draft 15 (, which is going to be, with very minor changes, the first Committee Specification Draft (CSD). This means that we are nearing the end of the process of creating the MQTT 5.0 specification. There is a 30 day review period for the CSD once it's officially published, then if changes are needed as a result of feedback, there will be a second CSD with a further review period, and so on. We anticipate that two CSDs will be sufficient.

To facilitate MQTT v 5.0 adoption and awareness in the community, and give feedback to the OASIS TC within the CSD review period, James Sutton and I are proposing to start work on implementations in Eclipse Paho. The rough plan is:

  1. Ian to write a Python "test" broker to enable client testing and a server implementation model.

  2. James to start work on a Java client implementation. This will probably be a completely new codebase, because the existing Java client was for a long time deliberately constrained to the Java 1.4.2 language level to be compatible with JavaME. A new code base will enable later Java language features to be fully exploited.

  3. Ian to write C and embedded C client implementations. I haven't decided yet whether or how to extend the current codebases or write new ones. My plan is to try extending, and if that proves excessively complex, to review that approach.

  4. After Java, James will probably look at JavaScript next.

@icraggs icraggs added the enhancement label Jul 26, 2017

@icraggs icraggs self-assigned this Jul 26, 2017

@icraggs icraggs added this to the 1.3 milestone Jul 26, 2017


This comment has been minimized.

Copy link
Contributor Author

icraggs commented Feb 16, 2018

  1. is done.
  2. is mostly done.
  3. Embedded C started - MQTTPacket done. MQTTClient yet to be done. I will extend the current codebases generally.

This comment has been minimized.

Copy link
Contributor Author

icraggs commented Feb 20, 2018

MQTTClient (synchronous) API design:

Functions to manipulate properties:

MQTTProperties_add(MQTTProperties* props, MQTTProperty* prop)
MQTTProperties_remove(MQTTProperties* props, int identifier)

struct MQTTV5Response
MQTTReasonCode reasonCode;
MQTTProperties* properties; // optional

MQTTV5Response* MQTTV5Client_connect(MQTTClient handle, MQTTClient_connectOptions* options, MQTTProperties* connectProps, MQTTProperties* willProps);

MQTTV5Response* MQTTV5Client_disconnect(MQTTClient handle, int timeout, MQTTReasonCode, MQTTProperties*);

MQTTV5Response* MQTTClient_subscribe(MQTTClient handle, const char* topic, int qos,
MQTTSubscribe_options* opts, MQTTProperties* props);

int MQTTV5Client_publishMessage(MQTTClient handle, const char* topicName, MQTTClient_message* msg, MQTTClient_deliveryToken* dt, MQTTProperties* props);

MQTTV5Response* MQTTV5Client_publish(MQTTClient handle, const char* topicName, int payloadlen, void* payload, int qos, int retained, MQTTClient_deliveryToken* dt, MQTTProperties* props);


This comment has been minimized.

Copy link
Contributor Author

icraggs commented Feb 20, 2018

For the async client, we already have option structures on each call which can be extended to include properties. For connect and disconnect:

int MQTTAsync_connect(MQTTAsync handle, const MQTTAsync_connectOptions* options);
int MQTTAsync_disconnect(MQTTAsync handle, const MQTTAsync_disconnectOptions* options);

We don't need to change the return code because the MQTT V5 Reason Code and properties will be returned in the success/failure callbacks.

For the other calls, the MQTTAsync_responseOptions structure can be extended to include properties which are input options, so the only real fly in this ointment is the name of the structure. We could create a synonym for that type so (MQTTAsync_callOptions or something) so that it didn't just imply it was for responses.

int MQTTAsync_subscribe(MQTTAsync handle, const char* topic, int qos, MQTTAsync_responseOptions* response);
int MQTTAsync_subscribeMany(MQTTAsync handle, int count, char* const* topic, int* qos, MQTTAsync_responseOptions* response);
int MQTTAsync_unsubscribe(MQTTAsync handle, const char* topic, MQTTAsync_responseOptions* response);
int MQTTAsync_unsubscribeMany(MQTTAsync handle, int count, char* const* topic, MQTTAsync_responseOptions* response);
int MQTTAsync_send(MQTTAsync handle, const char* destinationName, int payloadlen, void* payload, int qos, int retained, MQTTAsync_responseOptions* response);
int MQTTAsync_sendMessage(MQTTAsync handle, const char* destinationName, const MQTTAsync_message* msg, MQTTAsync_responseOptions* response);

The upshot is that I think we could end up only changing the structures rather than the API calls themselves. We'll need the operations on properties like the synchronous client as well of course.


This comment has been minimized.

Copy link

fpagliughi commented Mar 5, 2018

The Paho C++ and Rust libraries just wrap the Async API, so I'm mostly looking at this last comment. This seems like a reasonable way to proceed, with minimal disruption to the existing API and apps.

I wonder if, in C++, there might be a new class, call_options, that derives from the existing response_options, to signal intent. But I'm just thinking out loud.

BTW, nice use of const. :-)


This comment has been minimized.

Copy link
Contributor Author

icraggs commented Jun 27, 2018

Tracking this in the sub-issues now.

@icraggs icraggs closed this Jun 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.