Understanding MQTT QOS Levels- Part 1

mqtt-qosMQTT provides 3 QOS levels-

  • QOS 0 – Once (not guaranteed)
  • QOS 1 – At Least Once (guaranteed)
  • QOS 2 – Only Once (guaranteed)

The QOS levels are a way of guaranteeing message delivery and they  refer to the connection between a broker and a client.

In this two part tutorial we will look in detail at the message flow when publishing using all three QOS levels.

We also look at the advantages and disadvantages of using the various levels

QOS 0 –  Once

This is the fastest method and requires only 1 message. It is also the most unreliable transfer mode.

The message is not stored on the sender, and is not acknowledged.

The message will be delivered only once, or not at all.

Once the message has been sent by the client it is deleted from the outbound message queue.

Therefore with this QOS level there is no possibility of duplicate messages.

QOS 1 – At Least Once

Click To Enlarge

This level guarantees that the message will be delivered at least once, but may be delivered more than once. (See Flow Diagram on right.)

Publishing with QOS of 1 requires 2 messages.

The sender sends a message and waits for an acknowledgement (PUBACK).

If it receives an acknowledgement then it notifies the client app, and deletes the message from the outbound queue..

If it doesn’t receive an acknowledgement it will resend the message with the DUP flag set (Duplicate Flag).

The message will continue to be resent at regular intervals, until the sender receives an acknowledgement.

If the message is being sent to the broker then the broker will forward that message to subscribers even though the duplicate flag is set.

Therefore subscribers can receive the same message multiple times.

QOS 1 Example


For this example I have created a Python script to publish messages with a QOS of 1.

I have also hacked the Python Client Class so that I can suppress reception of the PUBACK message to simulate a network failure.

In addition I have a monitor subscribed to the topics that I’m publishing on, so I can see all published messages.

The example tries to illustrate:

  • Message Flow for QOS 0 and QOS 1 Messages
  • Normal QOS level 0 publish
  • Normal QOS 1 publish and message deletion
  • How Unacknowledged messages are handled
  • Message re-sending on failure
  • Duplicate Flag usage
  • Message storage on Client in case of disconnection
  • Duplicate messages with QOS level 1

Step 1

To start we do a simple publish with QOS=1 and observe the PUBACK being received, the message being marked as delivered, and removed from the outbound message queue.

Then we simulate a network problem by blocking PUBACK message. Now you should notice that the message remains stuck in the outbound message queue.


Step 2

Now we publish two more messages the first with QOS of 0. This message doesn’t have a PUBACK and is removed from the message queue once sent.

The second message is sent with a QOS of 1 and remains stuck in the outbound queue even though it has been sent .


Step 3

Now the client attempts to resend the message held in the queue (MID=2). Notice the Duplicate flag is now set.


Step 4

Now will simulate a dropped connection by doing a disconnect and reconnect. You can see that the messages (m2 and m4) are still in the queue, and the client re-sends the messages with the duplicate flag set.


Step 5

Now we change the setting to let the PUBACK messages come through.


Step 6

After a short time the client republishes the messages again, but this time the PUBACK  is received OK, and the messages finally get removed from the outbound queue.


Step 7

Here is what is seen on the monitor notice the duplicate messages.


In Part 2 we look in detail at publishing using QOS 2.

Related Tutorials and Resources:

Please rate? And use Comments to let me know more
[Total: 9   Average: 4.6/5]


  1. Hey,
    first of all, nice tutorial. Clear and concise explanation
    I have a doubt, who actually publishes the PUBACK? Is it being done by the client who has subscribed or by the broker, who knows that the message is actually delivered to the client?

    Dhaval Shah

  2. Thank you for the helpful information.

    For my application which includes a database I was interested in reliable delivery. In my searches I’ve found this is rarely addressed. My conclusions are that it is not possible with commonly used software. paho mqtt provides no way for the app to acknowledge receipt of a message so presumably the message is lost if the power goes out between when paho acks the message and when the app commits it to persistent storage. In addition, the mosquitto broker writes persistent info to disk based on a timer so there is a 30 minute (changable) window when a power failure will cause loss of all acknowledged but undelivered messages.

    1. Hi
      You can’t configure QOS on Mosquitto. QOS is done on the client publish and subscribe.
      The only time you configure QOS on Mosquitto is when it is used as a bridge and in this case Mosquitto functions like a client.

  3. Why there is a need of QoS when TCP/IP gives guaranteed delivery mechanism already? All retry, failure, duplicate is taken care by TCP itself.

  4. Your tutorials are great and I love reading them. It would be really helpful if you can order the MQTT tutorials in series or like chapters so that we would know which topic to read next. Thank you so much.

    1. Glad you fin them useful and Tks for the reminder. I’ve been meaning to put them into some form of course for a while.
      Any suggestions on what is missing would be appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *