Understanding mqtt subscriber qos

Question

I am new to MQTT and I just learned about the meaning of the QOS level that is decided when a message is published:

• 0 when we prefer that the message will not arrive at all rather than arrive twice
• 1 when we want the message to arrive at least once but don't care if it arrives twice (or more)
• 2 when we want the message to arrive exactly once. A higher QOS value means a slower transfer

I noticed that the subscriber side can also set the "Maximum QOS level they will receive". Quoting from here:

For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0.

Does this mean that the message might not arrive to the client (QOS 0) despite the fact that publisher sent it with QOS 2?

This might be a big issue among inexperienced developers - for example, the default QOS of the subscribe function in the npm mqtt package is 0! (The default should have been the maximum value 2 in my opinion, i.e. "let the publisher decide the QOS").

Forewing

Answer 1

You are correct, there is no guarantee that a message published at QoS 2 will arrive at a subscriber who is using QoS 0. If it is important for that subscriber to receive the message, they should be using QoS 1 or 2. That is something to decide for any given application.

I would rewrite your definition of QoS 0 as "at most once", i.e. the message will be received or it won't, there isn't a chance of a duplicate.

Regarding default QoS - I think most clients use QoS 0 as the default. I don't see that setting QoS 1 or 2 as the default would help the inexperienced developer, they still need to understand why and what they are doing and to consider the implications on their application.

Thetos

Please note that "QoS messages are never “upgraded”, so if the original publisher sent a message with QoS 0, a QoS 2 subscriber will still receive the message as QoS 0". More info at blog.famzah.net/2022/10/03/… – Allspice

Answer 2

A publisher really doesn't have a direct notion of what clients are subscribed to that message. A publisher's QOS level determines the quality of service in ensuring that the broker receives the publication. Once the broker receives the publication, it becomes responsible to re-send the message. [edit] The broker then resends the message to the subscribers, but only at most at the QoS that it received from the publisher. This may even be a downgrading of QoS that subscribers have specified.

I found this article quite helpful in understanding this concept.

Rompers

That's not right. "QoS messages are never “upgraded”, so if the original publisher sent a message with QoS 0, a QoS 2 subscriber will still receive the message as QoS 0". More info at blog.famzah.net/2022/10/03/… – Allspice

@famzah, I stand corrected. Thanks. I will alter my response. – Rompers

Answer 3

"Does this mean that the message might not arrive to the client (QOS 0) despite the fact that publisher sent it with QOS 2?"

Yes that is true. The publisher will want to publish at QOS 2 to ensure that the record arrives at the state layer only once (without duplicates). A layer of retrys + acks are used to ensure this. There is additional work for the brokers that provide the topic to subscribing clients to ensure that the message is delivered at the requested QOS level.

For example a message is published at QOS 1 and a subscriber to the same topic is subscribed at QOS 2, then the broker handling the delivery of the message to said subscriber will have to ensure that no duplicate is sent to the client.

In your example a publisher is publishing at QOS 2, so the state layer inserted the record once, and there is a subscriber at QOS 0 for this same topic. The subscriber may never receive this message. For example during message send there was a network hiccup and the record never arrived. Since there is no ack mechanism in QOS 0 the broker never attempts to redeliver.

Taeniafuge

QoS messages are never “upgraded”, so if the original publisher sent a message with QoS 1, a QoS 2 subscriber will still receive the message as QoS 1. More info at blog.famzah.net/2022/10/03/… – Allspice

Answer 4

i did't read MQTT protocol Specifications yet, just say my test with mosquitto 1.5.3.

1. run mosquitto server/broker

with default conf.

mosquitto -v

1541075091: mosquitto version 1.5.3 starting
1541075091: Using default config.

2. pub test msg

AAA sub topic 'aaa'
BBB sub topic '+'
DDD pub topic 'aaa'

3. the server stdout

1541075322: New connection from 10.1.1.159 on port 1883.
1541075322: New client connected from 10.1.1.159 as DDD (c1, k60).
1541075322: No will message specified.

1541075322: Sending CONNACK to DDD (0, 0)
1541075322: Received PUBLISH from DDD (d0, q1, r1, m1, 'aaa', ... (8 bytes))
1541075322: Sending PUBACK to DDD (Mid: 1)

1541075322: Sending PUBLISH to AAA (d0, q0, r0, m0, 'aaa', ... (8 bytes))
1541075322: Sending PUBLISH to BBB (d0, q0, r0, m0, 'aaa', ... (8 bytes))
1541075322: Received DISCONNECT from DDD
1541075322: Client DDD disconnected.

server PUBACK to DDD before PUBLISH the msg.

4. so i guess

pub qos=1 only make sure broker received the msg,
sub qos also:

[ pub ] ---pub_qos---> [ broker ] ---sub_qos--> [ sub ]

// MQTT clients and broker Network topology is star network.
// if i have time, i'll read the Protocol Specifications

Roach