The MQTT Technical Committee at OASIS continue to work on improvements to MQTT. The next version looks set to be MQTT version 5 and has reached the “working draft” stage. This post lists some of the changes that are in the working draft 02 and so gives at least a flavour of the improvements coming up. Take this with a pinch of salt, I may have missed some changes and there is no commitment that any of these features will remain in the final specification as they are described here.
In MQTT v3.1.1 and earlier, a client could control how the server treats its session with the clean session flag. If set to 1, the server would delete any existing session for that client and would not persist the session after disconnecting. If set to 0, the server would restore any existing session for a client when it reconnected, and persist the session when the client disconnected.
A session here means the subscriptions for a client and any queued messages.
The new spec changes this behaviour. The clean session flag has been renamed to clean start (this was actually the name of the flag in the old MQTT v3 spec) and now only affects how the broker handles a client session when the client connects. If set to 1, the server discards any previous session information, otherwise session information is kept.
To deal with removing of sessions at any other time, a new identifier/value pair has been introduced. These identifier/value pairs are an addition to the variable header part of some MQTT packets and allow configuring of different behaviour. In the case of the CONNECT packet, a Session Expiry interval can be specified which is a 4 byte integer that gives the number of seconds after a client has disconnected that the server should remove session information for that client. If the Session Expiry interval is absent from the CONNECT packet, then the session will never expire. If it is set to 0, then the session is removed as soon as the client disconnects.
The new clean start flag and session expiry interval allow the existing clean session behaviour to be duplicated but also allow client sessions to be expired based on time.
The return codes passed to the client in a CONNACK packet have been expanded to include:
When publishing data to a single topic, a new feature will help reduce bandwidth use. A client or server can set the topic in a PUBLISH message to be a zero length string. This tells the client/server being published to, to use the previous topic instead. This goes some way to reducing the current overhead associated with publishing – a shame it isn’t quite as good as the registered topics available in MQTT-SN.
Another identifier/value pair is available for use when sending a PUBLISH message. This is the Payload Format indicator. If present and set to 1, this indicates that the PUBLISH payload is UTF-8 encoded data. If set to 0, or if the indicator is not present then the payload is an unspecified byte format, exactly as with MQTT v3.1.1.
This is an identifier/value pair for use when publishing. If present, this value is a 4 byte integer which gives the number of seconds for which the server will attempt to deliver this message to a subscriber. This means that an offline client with messages being queued may not receive all of the messages when it reconnects, due to some of them expiring. Interestingly, when the server does deliver a message that had a Publication Expiry set, it sets the Publication Expiry on the outgoing message to the client but with the amount of time that there is left until the message expires. This means that the true time to expiry will propagate through bridges or similar.
The PUBACK and PUBREC packets have a new entry in their variable header which is the Publish Return Code. This can be used to tell the client a message has been refused for various reasons, accepted, or accepted with no matching subscribers. For the PUBREC packet, if the message is refused or accepted with no matching subscribers then there is no expectation for the PUBREL/PUBCOMP messages to be sent for that message.
The PUBCOMP packet also has a similar entry which has the same set of return codes and an additional one for the case when a message had expired. This is for the case when a client reconnects with clean start set to 0 and it has a QoS 2 message part way through its handshake, but the server has already expired the message.
There is still no way to tell a client that its QoS 0 message was refused.
In MQTT v3.1.1 and before, only the client sends a DISCONNECT packet. In the draft spec, either the client or the server can send DISCONNECT and it is used to indicate a reason for disconnection. The disconnect return codes are:
It is clear that there is some duplication there, so I think this is a likely place that changes will be made.
The DISCONNECT packet can also include a Session Expiry interval value, as with CONNECT. This allows a client to clean up when it disconnects, or to set a long expiry time, even if these were not specified at the initial connect.
To celebrate the new mosquitto logo, stickers are now available:
If you would like to obtain some stickers for yourself you have two options.
The first is to get in touch and I’ll send you some for a small contribution. This contribution is to cover the cost of the stickers plus postage: (cost of postage)+N*£0.45, where N is the number of sheets of 6 stickers that you want. Cost of postage for a letter can be calculated using the Royal Mail price finder, but should be £1.05 for destinations outside of the UK. Please also consider Paypal fees using a fees calculator to calculate the final sum. So for a single sheet of stickers posted internationally, the cost would be £1.76 including paypal fees. Two sheets would be £2.23.
The second option is to buy a full sticker book through moo.com. This can be done very easily by navigating to http://mosquitto.org/stickers/ This allows you to easily order a sticker book of 90 stickers with either the colour or blue monochrome stickers, or a mix of both.
There is a third option – get in touch to say why you deserve some stickers and maybe we’ll send you some. We’re looking for things that make us say “wow!” If you will be sending your sticker to space, getting mosquitto on television or using MQTT in your Formula 1 technology, these are all things that would exciting to see with a mosquitto sticker in place. If you want to give out stickers at a local IoT related event or similar that’s great, but we’d ask that you make a small donation. It’s only a small cost for you, but there are many people in your situation and it becomes a noticeable cost for the project.
Please do post links of your kit sporting any stickers you use!
The first round of the logo contest has closed and we now need to shortlist 6 designers. A selection of 20 logos have been chosen out of the 100 entrants and you are invited to vote on them and make comments. If you like a particular logo but not the colour, or like an idea behind the logo but not another element then please say so.
The links for voting (please do look at them all) are:
We have initiated a paid contest to create a new logo for the Mosquitto project.
If you have graphics design skills or know someone who has, please head over to the link below to see the design brief and submit your idea.
The mosquitto repository is now hosted on github: https://github.com/eclipse/mosquitto This is now the canonical location for mosquitto development work.
Bug reports should also be made on github and the existing bug reports will be migrated over shortly.
The documentation still needs updating with the new location and processes, so please do be patient with regards that.
Contributions can now be made through a github pull request. If you want to contribute a bug fix, please base your work off the “fixes” branch, if you are developing a new feature please use the “develop” branch.
Here’s to a new stage in the mosquitto project!
This is a security bugfix release. Any users of the “mount_point” feature are strongly advised to upgrade because versions prior to 1.4.8 allow clients to inject messages outside of their mount_point through the use of a Will.
This is a bugfix release. The changes below include the changes for 1.4.6, which wasn’t announced.
If you want to use TLS certificates you’ve generated using the Let’s Encrypt service, this is how you should configure your listener (replace “example.com” with your own domain of course):
First you need a copy of the root certificate. This will either be the ISRG Root X1, or IdenTrust DST Root CA X3. You need to check which of these root CAs signed the intermediate certificate you are using:
openssl x509 -in /etc/letsencrypt/live/example.com/chain.pem -noout -issuer
If your intermediate was issued by the ISRG root then use:
Otherwise you should go to https://www.identrust.com/certificates/trustid/root-download-x3.html to get the DST root certificate. Open a text editor, and paste the contents from that link, surrounding the text with the BEGIN and END lines as below:
pasted content goes here
Then, each time after your script to automatically generate your certificates runs you should also run:
cat /etc/letsencrypt/live/example.com/chain.pem /etc/letsencrypt/<your root>.pem > /etc/letsencrypt/live/example.com/chain-ca.pem
Then use the following for your mosquitto.conf:
You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.