Quality of Service

MQTT was designed to be rugged. The sensors or what have you publishing, may not always be available. They may go offline for whatever reason. A bird picked up the sensor, or the car drove through a tunnel. The real world is pretty unpredictable by the standards of application design. While we can’t ever be 100%, we can mitigate some of these problems. MQTT’s Quality of Service can help.

The quality of service defines the semantics of how the message published is delivered. There are 3 qualities of service, and a few options that are related, that we’ll cover here.

The ratings for quality of service are 0,1,and 2. Otherwise known as “At most once”, “At least once”, “Exactly once”, respectively.

QOS 0, or At Most once

At most once means that when a message is sent from the publisher, it is only relayed by the broker once. If there is some reason that the subscriber doesn’t receive it (for example, a netsplit, or their incoming buffers are full) then that is their fault, and the message is lost. While this seems pretty dire, there are very many messages that don’t need 100% accuracy. Sometimes the costs of storing messages to be resent outweighs the cost of missing them.

QOS 1, or At least once

With this setting, the broker re-sends the message until it has been acknowledged by the subscriber. That means that it is possible for the receiver to get the message more than once, because of a gap between transmission and reception times, for whatever reason. For idempotent operations, this is totally okay, and is useful sometimes, when you want to assure that a message has been received, but don’t want the heavier semantics of QOS 2.

QOS 2, or Exactly once

Quality of service 2 will communicate with the subscriber before publishing, and ask them if they’re ready to receive the publish. It will hold onto the publish until they assent to having it sent to them. Useful in the case of chat programs, and other highly important, but perhaps not millisecond-sensitive transactions.