MQTT supports different levels of message delivery assurance. There are three QoS levels: QoS 0 (at most once), QoS 1 (at least once), and QoS 2 (exactly once). The QoS level determines the reliability and guarantee of message delivery. 

When an MQTT message is sent, it follows two distinct delivery paths: one from the publishing client to the MQTT broker and another from the MQTT broker to the subscribing clients. The Quality of Service (QoS) level chosen for the message applies to both of these delivery paths. 

From a publisher to a broker

The client that publishes the message to the MQTT broker defines the QoS level of the message when it sends the message to the MQTT broker. 

From the broker to a subscriber

When subscribing to an MQTT topic, subscribing clients have the ability to specify the desired QoS (Quality of Service) level for the messages they will receive. The subscribing clients can indicate their preferred QoS level during the subscription process. 

 When a message is published to the subscribed topic, the MQTT broker checks the QoS level specified by the subscribing clients during the subscription process. The MQTT broker delivers the published message to the subscribing clients with the QoS level that matches or is lower than the specified QoS level.  

For example, where the publishing client sends a message with QoS 1 and the subscribing client subscribes to the topic with QoS 2, the MQTT broker will use the lower of the two QoS levels ( QoS 1) when delivering the message to the subscribing client. 

In this case, the subscribing client's request for QoS 2 indicates its preference for higher reliability and assured delivery, but since the message was published with QoS 1, the broker cannot provide a higher level of reliability than what was initially requested by the publishing client. Therefore, the broker will deliver the message to the subscribing client with QoS 1 to maintain compatibility with the original QoS level of the message.

On the contrary, if the subscribing client defines a lower QoS than the publishing client, the broker transmits the message with the lower quality of service.

In MQTT, the QoS level of a message is determined by the sender (publishing client) and not the receiver (subscribing client). The receiver can specify its desired QoS level during the subscription process, but it does not influence the QoS level used by the sender. 

Just remember, the MQTT broker will use the lower of the two QoS levels when delivering the message to the subscribing client. 

QoS Summary

* When using QoS 1 and QoS 2, messages sent to offline clients are queued by the MQTT broker until the client with persistent session becomes available again. we will explain more about queueing message at the bottom of this article.

QoS 0 - the lowest level

QoS 0 is the lowest level of quality of service in MQTT protocol. It is also known as "fire and forget" or "at most once" delivery.

In QoS 0, the publisher sends a message to the broker without any acknowledgment or assurance of delivery. The message is not stored and re-transmitted by the publisher. 

Once the message is published, the broker will immediately distribute it to all current subscribers of the topic. However, the broker does not keep track of whether the message is successfully received by the subscribers. If a subscriber is not currently connected or if it misses the message for any reason, it will not receive the message.

QoS 0 provides the lowest overhead and latency since there is no need for acknowledgment or retransmission. It is suitable for applications where occasional message loss or duplication is acceptable.

Here are a few key characteristics of QoS 0:

1. Message loss: If a subscriber is not connected when a message is published, it will not receive that particular message. There is no retransmission of messages in QoS 0, so once a message is published, it is considered delivered.

2. No acknowledgment: The publisher does not receive any acknowledgment from the broker or subscribers when a message is successfully delivered or received by MQTT broker.

3. Lowest overhead: QoS 0 has the least amount of overhead since it does not involve additional message exchanges for acknowledgment or retransmission.

4. Fast delivery: Messages published with QoS 0 are delivered immediately to the subscribers who are currently connected to the topic.

While QoS 0 provides the least reliability compared to higher QoS levels (QoS 1 and QoS 2), it is still useful in scenarios where loss or duplication of messages can be tolerated without significant impact. It is often employed in applications where real-time data updates are more critical than guaranteed delivery, such as sensor data collection or live streaming applications.

QoS 1 - The default level

QoS 1 provides a higher level of reliability and assurance compared to QoS 0. 

QoS level 1 in MQTT guarantees that a message is delivered at least one time to the receiver. The sender (publishing client) stores the message until it receives a PUBACK (Publish Acknowledgment) packet from the MQTT broker, which acknowledges the receipt of the message. If the sender does not receive a PUBACK within a certain time frame, it will retransmit the message to ensure its delivery.

When the MQTT broker receives a message with QoS 1, it forwards the message to all subscribing clients and responds with a PUBACK packet to the sender. This PUBACK packet serves as an acknowledgment to the sender, confirming that the message has been successfully received by the broker.

It is possible for a message to be sent or delivered multiple times due to retransmissions in QoS 1. This can occur if the PUBACK acknowledgment is not received by the sender within a specific timeframe. The MQTT broker ensures that the message is delivered to the subscribing clients at least once, but duplicate messages may be received by the clients if retransmissions take place.

Here are the key characteristics of QoS 1:

1. At Least Once Delivery: When a message is published with QoS 1, the MQTT broker ensures that it is delivered to the subscribing client at least once. The broker acknowledges the receipt of the message from the publishing client and stores it until it can be successfully delivered to the subscriber.

2. Message Acknowledgment: After the broker receives a message published with QoS 1,it forwards the message to all subscribing clients immiediately and then  sends an acknowledgment (PUBACK) to the publishing client. This acknowledgment informs the publishing client that the message has been successfully received and processed by the broker.

3. Possible Message Duplication: In QoS 1, there is a possibility of message duplication due to retransmission attempts. If the broker does not receive an acknowledgment from the subscriber within a certain time frame, it will retransmit the message to ensure delivery. As a result, the subscriber may receive duplicate copies of the message.

4. No Ordering Guarantee: While QoS 1 ensures at least once delivery, it does not guarantee the order of message arrival. If multiple messages are published with QoS 1, they may be delivered to the subscriber out of order due to variations in network conditions or message processing delays.

QoS 1 strikes a balance between reliability and efficiency. It provides assurance that messages are delivered to subscribers but does not guarantee exactly once delivery or strict ordering. It is suitable for scenarios where occasional duplicate messages or out-of-order delivery can be tolerated, but reliability is still important.

QoS 2 - the Highest Level 

QoS 2 is the highest level of reliability and assurance in MQTT protocol. It provides end-to-end, exactly-once, strict ordering message delivery between the publishing client and the subscribing client.

Here are the key characteristics of QoS 2:

1. Exactly Once Delivery: QoS 2 guarantees that a message is delivered exactly once to the subscribing client. The MQTT broker ensures that the message is received and acknowledged by the subscriber, and it takes necessary measures to prevent duplication.

2. Strict Ordering: QoS 2 ensures strict ordering of messages. If multiple messages are published with QoS 2, the broker and subscribers guarantee the correct order of message arrival, preserving the sequence in which the messages were published.

3. No Message Loss or Duplication: QoS 2 guarantees no message loss or duplication. The broker retains and tracks the state of the message exchange to ensure that it is delivered exactly once to the subscriber.

QoS 2 is the most reliable but also the most resource-intensive option among the QoS levels. It involves multiple message exchanges and requires additional overhead for tracking state and ensuring exactly once delivery. Therefore, it is typically used in scenarios where message integrity and reliability are critical, such as financial transactions, critical system updates, or situations where duplications or losses of messages are unacceptable.

Technically, QoS 2 employs a four-step message exchange process involving the publishing client, MQTT broker, and subscribing client. Let's look at each step in detail:

1. Publish:

   • The publishing client sends the message to the MQTT broker with QoS 2.

2. Pubrec (Publish Received):

   • The broker sends a Pubrec packet as an acknowledgment to the publishing client.
   • The Pubrec packet confirms that the broker has received the message and indicates that the broker is ready to proceed with the delivery process.
   • If the publishing client does not receive a Pubrec packet within a specific timeframe, it retransmits the message to the broker.

3. Pubrel (Publish Release):

   • The subscribing client, upon receiving the message from the broker, sends a Pubrel packet.

4. Pubcomp (Publish Complete):

   • The broker acknowledges the successful delivery of the message to the subscribing client by sending a Pubcomp packet.
   • The Pubcomp packet serves as a completion message to the publishing client, confirming that the message has been successfully delivered.

By utilizing this robust message exchange mechanism, QoS 2 ensures that messages are reliably delivered exactly once, preserving the order of messages and preventing both loss and duplication.

It's worth noting that achieving QoS 2 requires additional network overhead, computational resources, and increased latency compared to lower QoS levels. Therefore, it should be used when strict message integrity and reliability are crucial, and the potential impact on performance is acceptable for the given application requirements.

Best Practice

The choice of which Quality of Service (QoS) level to use depends on the specific requirements and constraints of your application. Here are some general guidelines on when to use each QoS level:

1. QoS 0 (At Most Once):

   • Use QoS 0 when message loss or duplication is acceptable.
   • QoS 0 provides the lowest level of reliability, as it does not guarantee delivery or acknowledgment of messages.
   • It is suitable for scenarios where message delivery is not critical, and losing a message or receiving duplicate messages has minimal impact.
   • Examples include non-critical sensor data, live streaming, or situations where data transmission is frequent and losing occasional messages is acceptable.

2. QoS 1 (At Least Once):

   • Use QoS 1 when reliable delivery of messages is important, but duplicates can be tolerated.
   • QoS 1 guarantees that messages are delivered at least once to the subscribing client.
   • It involves a message acknowledgment mechanism to ensure reliable delivery, but duplicates may occur in case of retransmissions.
   • It is suitable for scenarios where occasional message duplication is acceptable, and message reliability is a priority.
   • Examples include system commands, status updates, or situations where it is crucial to ensure messages reach the intended recipient, even if duplicates may be received.

3. QoS 2 (Exactly Once):

   • Use QoS 2 when strict message integrity and ordering are critical, and duplicates or losses are unacceptable.
   • QoS 2 guarantees end-to-end, exactly-once delivery of messages.
   • It involves a more complex four-step message exchange mechanism to ensure the highest level of reliability, without message duplication or loss.
   • It is suitable for scenarios where message integrity and order must be maintained, such as financial transactions, critical system updates, or scenarios with strict data consistency requirements.
   • However, QoS 2 introduces higher network overhead and latency compared to QoS 0 and QoS 1.

In summary, choose the appropriate QoS level based on the specific needs of your application. Consider factors such as the importance of message delivery, tolerance for duplicates or losses, network constraints, and the trade-off between reliability and performance overhead. It's important to strike a balance between reliability and efficiency while meeting the requirements of your particular use case.

Queueing the message

When using QoS 1 and QoS 2 in MQTT (Message Queuing Telemetry Transport) protocol, messages sent to offline clients are queued by the MQTT broker until the client becomes available again. However, it's important to note that this queuing is only possible if the client has a persistent session with the broker.

Here's how it works:

1. Persistent Session: MQTT clients can establish a persistent session with the MQTT broker by setting the "Clean Session" flag to false when connecting. This means that the client intends to maintain its connection and have the ability to receive messages even when it is offline or experiences temporary disconnections.

2. Offline Clients: If an MQTT client with a persistent session is offline or disconnected temporarily, any messages published to it with QoS 1 or QoS 2 are stored by the broker until the client reconnects.

3. Queuing: The MQTT broker queues the messages for the offline client, ensuring they are retained and available for delivery when the client becomes online again. The broker keeps track of the client's subscription information and the QoS level of the messages.

4. Delivery Upon Reconnection: When the client reconnects to the MQTT broker, it re-establishes its session and retrieves the queued messages. The broker delivers the queued messages to the client according to the QoS level specified when the messages were originally published.

It's important to highlight that the queuing of messages for offline clients is only possible when the client has a persistent session. If the client connects with the "Clean Session" flag set to true, indicating a non-persistent session, the broker will not store and queue messages for the client while it is offline. In such cases, any messages published during the client's offline period would be lost.

By using persistent sessions and queuing mechanisms, MQTT ensures that messages sent with QoS 1 and QoS 2 are not lost when clients are temporarily offline and are delivered once they reconnect to the broker. This feature is especially valuable in scenarios where reliable message delivery is critical and where clients may experience intermittent connectivity or temporary outages.