Now that we understand how connection, subscription, and publication work in combination with topic names and topic filters with wildcards, we can dive deep into the QoS levels. So far, we have analyzed how both subscription and publication work with a QoS level equal to 0. Now, we will understand what this number means and how things work when we use the other available QoS levels for publication and subscription.
Remember that publication involves publishing from the MQTT client to the MQTT server and then from the server to the subscribed client. It is very important to understand that we can publish with a QoS level and subscribe with another QoS level. Hence, there is a QoS level for the publish process between the publisher and the MQTT server and another QoS level for the publish process between the MQTT server and the subscriber. We will use sender and receiver to identify the parties involved in message delivery for the different QoS levels. In the publish process between the publisher and the MQTT server, the publisher will be the sender and the MQTT server the receiver. In the publish process between the MQTT server and the subscriber, the sender will be the MQTT server and the receiver will be the subscriber.
Based on the QoS level, we have differences in the meaning of a successfully delivered message in the MQTT protocol between the involved parties. The QoS level is the agreement between a sender and a receiver of a message about the guarantees of actually delivering the message. These warranties might include the number of times that a message might arrive and the possibility (or not) of duplicates. MQTT supports the following three possible QoS levels:
- 0, At most once delivery: This QoS level offers the same warranty as the underlying TCP protocol. The message is not acknowledged by the receiver or destination. The sender just sends the message to the destination and nothing else happens. The sender neither stores nor schedules new deliveries for any messages that might fail to reach the destination. The key advantage of this QoS level is that it has the lowest possible overhead, compared to the other QoS levels.
- 1, At least once delivery: This QoS level adds a confirmation requirement to the destination that has to receive the message. This way, QoS level 1 provides a warranty that the message will be delivered at least once to the subscriber. One of the key disadvantages of this QoS level is that it might generate duplicates, that is, the same message might be sent more than once to the same destination. The sender stores the message until it receives an acknowledgment from the subscriber. If the sender doesn't receive the acknowledgment within a specific time, the sender will publish the message again to the receiver. The final receiver must have the necessary logic to detect duplicates if they shouldn't be processed twice.
- 2, Exactly once delivery: This QoS level provides a warranty that the message is delivered only once to the destination. QoS level 2 has the highest overhead, compared to the other QoS levels. This QoS level requires two flows between the sender and the receiver. A message published with QoS level 2 is considered successfully delivered after the sender is sure that it has been successfully received once by the destination.
Sometimes, we just want messages to be delivered with the least possible bandwidth usage, we have a very reliable network, and it doesn't matter if for some reason a few messages are lost. In these cases, QoS level 0 is the appropriate choice.
In other cases, the messages are extremely important because they represent commands to control an IoT device, the network is unreliable, and we must make sure that the message reaches the destination. In addition, a duplicate command might generate a big problem because we don't want the IoT device to process a specific command twice. In these cases, QoS level 2 is going to be the appropriate choice.