Skip to main content
Version: Mosquitto 2.1

Quality of Service

Quality of Service

The QoS (Quality of Service) defines a certain level of service that enables the publisher to make sure that the certainty and quantity of a subscriber receiving a sent message equal the importance to receive the message at all, plus whether to receive the message only once.

Also, a subscriber can set a QoS, defining the importance to receive every message, and whether to accept one message multiple times or not.

info

It is important to understand that the QoS level can be seperate for each message transfer: 1.) Publisher -> Broker 2.) Broker -> Subscriber

Example: The Publisher publishes a message with QoS level 1. The transfer from the publisher to the broker will therefore be using QoS level 1. After that the broker forwards the message to the subscriber. But the subscriber has subscribed to the topic only using QoS level 0. Therefore the message transfer from the broker to the subscriber will be with QoS level 0.

info

Important: The broker can not deliver a message with a higher QoS level than it has received by the publisher.

Example: The publisher is publishing the message using QoS level 1. But the subscriber has subscribed to the topic with QoS level 2. The broker will therefore forward the message to the subscriber using QoS level 1.

There are three levels available:

QoS0 - at most once

QoS0 is the minimum QoS level.

The broker/client is delivering the message only once, without confirmation.

qos0

There is no guarantee that the message sent has been sent to the subscriber. The recipient on the other end does not acknowledge the receipt. Neither is the acknowledgment stored.

The QoS0 - level is often referred to be the "fire and forget"-level.

Using the minimum level of quality can make sense, as MQTT requires to be lightweight, bandwidth-saving, and super fast delivery. QoS0 does not require as many resources on the broker.

A subscriber can also use QoS0.

qos0+qos0

QoS1 - At least once

Level 1 QoS guarantees the delivery of a message to the receiver at least once.

qos1

However, "at least once" means that a single message can be transmitted to the receiver more than once. Thus, this QoS level ensures that a message reaches its subscribers but does not care about how many times that might be the case.

And the message is stored until the broker receives an acknowledgment.

On the other hand, you really should think about the disadvantages as QoS1 occupies resources.

Whether to use QoS1 or QoS0 you might want to make up your mind before setting up the broker.

info

Digression: How the acknowledgment works

The subscriber must send a so-called PUBACK packet (publish acknowledge) to the broker when the broker demands acknowledgment.

If the subscriber does not send a PUBACK, the broker continues sending PUBLISH packets. If the broker sends the PUBLISH packet again, even the second time, it contains a duplicate flag (DUP).

The packetId enables the broker to match the PUBLISH packet and PUBACK packet. And the packetId is free and reusable again.

The publishing client must store all QoS1 messages sent to the broker without confirmation from the broker.

The broker must store:

  • The information that the session still exists.

  • All subscriptions a client subscribed to.

  • The QoS1 messages waiting to be sent to the client.

  • The QoS1 message, will message and will delay the interval that the client received, but without confirmation.

A subscriber can also use QoS1.

qos0+qos1

QoS2 - Exactly once

QoS level 2 guarantees each message is received exactly once.

qos2

To do as pleased the broker transmits the PUBLISH packet as usual. But the recipient must respond with a PUBREC Publish Release).

After that happens, the broker sends another request (PUBREL), and the recipient must respond again.

The publishing client must store all QoS2 messages sent to the broker without confirmation from the broker.

The broker must store:

  • The information that the session still exists.

  • All subscriptions a client subscribed to.

  • The QoS2 messages waiting to be sent to the client.

  • The QoS2 message, will message and will delay the interval that the client received, but without confirmation.

To discard all stored states and answers a so-called PUBCOMP packet (Publish complete) is sent. That's the end of the QoS2 order of events.

Until a PUBCOMP is sent, the broker stores a reference of the original PUBLISH packets packetId.

The packet and packetId become reusable again.

A subscriber can also use QoS2.

qos0+qos2

To define which level of Quality of Service you should use, this may help you:

  • QoS0:

The connection between sender and receiver is stable. In addition, it's no problem to miss out on several sent messages if there might be problems with the connection stability.

Also, message queueing is not needed.

  • QoS1:

The receiver must receive every message sent. Also, your setup can handle the duplicate message. Still, QoS2 is too much overhead for your connection (also QoS1 delivers messages faster than QoS2).

caution

Attention

QoS1 needs way more resources than QoS0. (#).

  • QoS2:

Your system must be fed with every message exactly once. Duplicate messages are not wanted or might even manipulate the system.

Also, the loss of a message is crucial. Often QoS2 is set whenever the loss of messages may result in loss of life, e.g. clinical surgery, or property, e.g. stock trading.

Some industries such as a bank, firefight, aviation, etc require high completeness of data and timeliness.

QoS2 bears the possibility of overhead.

info

What happens if the connection gets lost after the subscriber received the message?

In that case the subscriber already forwarded the message's payload to the application that is connected. But at the same moment the subscriber is logging that the message with ID X has been received.

So when the broker sends the message again, in order to receive a PUBACK or PUBCOMP, the subscriber does not forward the payload to the application, but responds to the broker.