Supported MQTT Versions
MQTT Version 3.1: https://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
MQTT Version 3.1.1: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
The MQTT version 5.0 is the next development step in the evolution of MQTT.
Learn about the Eclipse Foundation.
Major bugs have been erased. For example in many cases errors led to disconnecting the client from the broker. With v.5.0 negative acknowledgements help to work out ways to solve the problem.
As the name suggests, the "Message expiry" feature allows you to set a length of time the message is valid. As the time runs out, the broker is no longer delivering the message to subscribers anymore.
MQTT v3.1.1 does not stipulate the expiration of persistent sessions. Any persistent session, if not personified by the client, runs endlessly.
Following the number of persistent sessions still running, but not in use, will occupy the resource of the server with time.
System architects build expiration times for the use of persistent sessions to face that problem.
MQTT 5.0 divides the "Clean Session" into "Clean Start" and "Session Expiry Interval".
Clean Start specifies whether a new session is needed as the client reconnects again.
Read more about Clean Start: Here. And here. And here. And here.
Session Expiry Interval specifies the session expiration time.
Read more about Session Expiry Interval: Here. And here. And here.
Both, "Clean Start" and "Session Expiry Interval" are specified when connecting.
Add a retainFlag to turn your last sent message in a retained message.
A retained message safes the last known value of the topic.
As soon as a publisher disconnects ungracefully from the broker. The retained message gets delivered to all new subscribers.
Let's take a open car door as example. The driver will want to know whether the car door is open and not closed as the car battery comes on again after the car died.
It's only possible to save up to one retained message, equal to one retained value.
The session terminates when the client disconnects using a DISCONNECT packet.
You can attach metadata to the MQTT packet.
MQTT can be mingled with many more extensions.
Client and server restrictions
Read more about Limitations: Here. And here.
Negative acknowledgments notify the client whenever an error occurs.
In MQTT v3.1.1 this may lead to disconnecting the client from the broker.
The client had to subscribe to the topics again.
v.5 gives the subscriber a chance to react before disconnection (best case scenario).
The packet sent in case of a negative acknowledgement gives the client all the information needed to make the necessary changes without having to contact operations or support to know what went wrong.
And how to successfully uphold the connection.
Example: A subscriber wants to unsubscribe from a topic.
In earlier MQTT versions whenever an error occurred during the unsubscribing-process chances were high this may led to disconnecting the client from the broker.
Version 5 helps the client to react before disconnecting.
Will delay interval
The will delay interval affects when the LWT is published after a client disconnects unexpectedly.
The idea is that a client is setting a LWT - Last Will and Testament - as it connects. Whenever the client disconnects unexpectedly, the broker publishes the message set as LWT on the clients behalf.
The LWT acts as a failure message for others to know that the client has failed.
A possible LWT message could therefore be "Client AXY has disconnected disgracefully".
If the client disconnects only briefly, there may not be a need to have the LWT sent.
Setting a will delay interval means the original persistent client can reconnect within the set time and the LWT will not be published.
The will delay interval is set at 5seconds.
The clients disconnects ungracefully.
The client reconnects within 5 seconds. The LWT is not sent.
If it does not reconnect after 5 seconds, the LWT is published.
Imagine a few clients subscribe to a topic. But the messages published are only received by one of the subscribers. That is what "Shared subscriptions" enable.
Read more about Subscriptions.
The workload of the messages sent are getting distributed.
Whenever a client makes a subscription, it does so with a topic, which is a string. v.5 clients can also set a subscription identifier, which is an integer number. If that is set, then when messages matching that subscription are sent to the client by the broker, the broker also attaches the subscription identifier for the subscription that matched.