MQTT QoS Level 0 – At Most Once
When the client sends a message to a broker with this level, it means the client sends the message only once and the broker does not acknowledge that the message is received. This means that there is no guarantee that the message being sent by the client is being received by the broker.
This service level should used if:
- Internet is reliable.
- Message loss in a small scale is manageable
- Messages need to be delivered fast
MQTT QoS Level 1 – At Least Once
With QoS level 1, the broker sends an acknowledgement(PUBACK) message after the client publishes each message with this service level. The message is stored by the client until it gets a PUBACK message from the client. This guarantees that the message that is delivered is received by the broker.
If a client subscribes to a topic on a broker with QoS level 1 and if a message is published to that topic, then the broker sends that message to all the clients and expects a PUBACK message from the client. This ensures that the subscribing client receives all the messages that is published to that topic.
In both cases, if the sender does not recieve a PUBACK message within some amount of time, the message is republished to the recipients with a duplicate flag(DUP). The DUP flag is not processed by the client or the broker but can be used based on your requirement in your program.
While QoS level 1 guarantees that the message is being received, it can create duplicate messages. This service level is slower than Level 0.
This service level should used if:
- All messages need to reach the client(s) or the topic on the broker.
- Duplicate messages can be handled properly.
MQTT QoS level 1 is widely used in commercial MQTT brokers like AWS IoT, Azure etc. Most commercial MQTT brokers do not support QoS level 2.
MQTT QoS Level 2 – Exactly Once
MQTT QoS Level 1 can cause duplicate messages to get processed. If you don’t have any proper mechanisms to handle the duplicate messages then duplicate data can get inserted to the database. Instead of relying on a mechanism to handle message duplication, we can use QoS Level 2. This service level guarantees that the message is sent only once!
The steps involved in QoS Level 2 are as follows:
1. When a receiver receives a message with QoS Level 2, it replies with a PUBlish RECeived(PUBREC) message that acknowledges that the message has been received. If the sender does not receive the PUBREC message, it will republish the message with a DUP flag.
2. The sender removes the first publish message after receiving the PUBREC message and sends a PUBlish RELease(PUBREL) message to the receiver. If the sender does not receive the PUBREL message, it will resend the PUBREL message with a DUP flag.
3. The receiver sends a PUBlish COMplete(PUBCOMP) message to the sender. If the sender does not receive the PUBCOMP message, then the PUBREL message is resent.
4. The sender removes the message from the queue.
QoS Level 2 is much slower than Level 1 or 0 because of the number of steps involved. Most commercial brokers like AWS IoT & Azure IoT do not support QoS Level 2 as on this post’s date.
This service level should be used if:
- Speed of message delivery & processing can be slower.
- Messages cannot not be duplicated.
Frequently Asked Questions
If a client publishes with QoS Level 2 and another client is subscribed to that topic with QoS Level 0, which QoS Level will be used?
The QoS Level is restricted to client to broker or broker to client communication. So if I publish a message with QoS Level 2, the message guarantee is only applicable from THAT client to the broker. If another client is subscribed to a topic on that broker with QoS Level 0, then the broker will send messages to that client only with QoS Level 0.
Does message queuing work with QoS Level 0?
No message queuing will not happen when a client publishes to or is subscribed to a topic with QoS Level 0. Message Queuing is possible only if persistent session is enabled by the client.