2
votes

I am using MQTT in embedded applications. I have gone through the documentation extensively and I understand how QoS feature is implemented in MQTT, and what each value means.

As it is known, MQTT does QoS downgrade, which means that a message will be delivered with the lowest QoS value between the sender and the receiver. This is understood, and for most of the QoS compinations between sending and receiving this makes sense.

However I have problem with a specific situation. What happens when a message is published with QoS 1 while a client has a subscription of QoS 2?

The message will be delivered at least once to the broker, which means that it may be delivered more than once. On the other hand the subscribing client expects that it is guaranteed to receive a message exactly once, which is not the case.

How can one overcome this serious issue? Essentially I cannot trust the QoS 2 setting.

(Note, normally this wouldn't be an issue as I could just publish the messages with QoS 2. However this becomes a problem when the publishing clients are out of your control, and there is no guarantee which QoS they will use.)

1

1 Answers

3
votes

As you already pointed out, when the original sender sends the message to the broker with QoS 1, the message may arrive multiple times at the broker, which means the broker could deliver this message to the (QoS 2) subscriber also multiple times. Since the time between the first QoS 1 message and the second can be very long (in case the original sender is offline after the original sending and so the re-delivery happens at a later point of time), exactly-once-guarantees would be very hard to guarantee on the broker side for the subscribers of the message.

In essence, make sure your client can handle duplicates if you can't make sure you only receive QoS 2 messages. You can e.g. use unique identifiers in your application payload for ensuring the message is isn't a duplicate on the business level.