I may not have finished all my goals for the test material in the Eclipse Paho project, as outlined in this blog post of mine, but some components are still useful in their current state.
Recently my IBM and Paho colleague, James Sutton, needed to check the behaviour of the Java and Android clients when receiving an error code in response to an MQTT subscribe request. This error code, returned in the MQTT suback packet, was introduced in the last, and current, version of MQTT, 3.1.1. It takes the form of an 0x80 value in the granted QoS (Quality of Service) field, for which only 0, 1 or 2 are valid values – the set of integers which QoS can take in MQTT.
Now you could fire up a broker like Eclipse Mosquitto and configure it to disallow a subscription to a certain topic. If you know the broker well enough, this may be quick and easy. It’s possible you might have to do some fishing around, and figure out whether that broker is actually returning 0x80 as you wanted.
So James turned to the Paho test broker (startbroker.py in this repo.) (You must use Python 3 to run it, not Python 2). As it stands, this broker will return 0x80 if you try to subscribe to the topic “test/nosubscribe” (see line 322 in MQTTBrokers.py). That’s pretty easy. If you checked out that file, you will notice another two topics: “test/QoS 1 only” and “test/QoS 0 only”, which will return granted QoSs of a maximum of 1 and 0 respectively. These behaviours can be hard to elicit out of a standard MQTT broker.
Ultimately I guess I should make the specific topics which these responses are attached to configurable, but they aren’t right now.
There are some other characteristics of this broker, which single it out as a “test” broker rather than a product:
- the goal of the coding is clarity rather than performance. You can tell me whether I succeeded
- there is no persistence: if you want to simulate stopping and restarting a broker, this broker can just remain running, and disconnect all clients
- MQTT specification conformance statements are embedded in the code, so that when a test suite is run against the broker, it can tell you which statements were encountered, and which weren’t.
- the broker has parameters to choose behaviours which can vary but still conform to the MQTT specification:
- whether to publish QoS 2 messages on PUBREL or not
- whether multiple matching subscriptions result in one publication, or more than one
- whether queued QoS 0 messages are dropped if the client is disconnected, or not
- whether zero_length_clientids are allowed
it’s possible more might be added in the future.
The main missing feature of this broker is TLS – but it does have WebSocket support. TLS is on my to do list, as will be updates for the next version of MQTT, 5, which we are working on, and is tentatively scheduled for completion next year.
As outlined in the blog post, this broker is meant to help with broker testing as well, as an oracle.
For some more information, see the Eclipse Paho website for the test tools.
You can use issues on this project to ask for new features or identify bugs, or pull requests to offer your own contributions.