129 lines
5.9 KiB
Markdown
129 lines
5.9 KiB
Markdown
|
<!--
|
|||
|
|
.. title: MQTT v5 draft features
|
|||
|
|
.. slug: mqtt-v5-draft-features
|
|||
|
|
.. date: 2016-08-15 19:23:48
|
|||
|
|
.. tags: MQTT
|
|||
|
|
.. category:
|
|||
|
|
.. link:
|
|||
|
|
.. description:
|
|||
|
|
.. type: text
|
|||
|
|
-->
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Session management
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Updated Connect Return codes
|
|||
|
|
|
|||
|
|
The return codes passed to the client in a CONNACK packet have been expanded to
|
|||
|
|
include:
|
|||
|
|
|
|||
|
|
* 6: Connection Refused, reason unspecified
|
|||
|
|
* 7: Connection Refused, implementation specific
|
|||
|
|
* 8: Connection Refused, CONNECT packet was malformed
|
|||
|
|
|
|||
|
|
# Repeated topics when publishing
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Payload Format Indicator
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Publication Expiry interval
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Publish Return Codes
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
# Disconnect notification
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
* 0: Connection disconnected by application (sent by client)
|
|||
|
|
* 1: Server temporarily unavailable (server)
|
|||
|
|
* 2: Server unavailable (server)
|
|||
|
|
* 3: Malformed UNSUBSCRIBE packet received (server)
|
|||
|
|
* 4: Session taken over (server - for when another client connects with the same ID)
|
|||
|
|
* 5: Malformed packet received
|
|||
|
|
|
|||
|
|
It is clear that there is some duplication there, so I think this is a likely
|
|||
|
|
place that changes will be made.
|
|||
|
|
|
|||
|
|
# Disconnect expiry notification
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
[MQTT Technical Committee]: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt
|