QoS = 0 level semantics for disconnected clients

[Zvi]

Hi,

for messages published with QoS=0, when subscriber was disconnected,
should broker drop such a messages or should it queue them, in case
client will reconnect shortly with CleanSession=false ?

We currently queuing them, with some timeout logic deciding when to
clean this queue (i.e. if client do not reconnect within 30 seconds -
drop all it's queued messages).

The spec uses "Best-effort" or "At most once. Fire and forget"
wording, which is not formal.
It should be specifically stated if messages should be dropped or
queued (at least temporarily) for QoS=0.

-----------------

QoS value Description
0 At most once Fire and Forget <=1
1 At least once Acknowledged delivery >=1
2 Exactly once Assured delivery =1

---------------

Three QOS levels:
Level 0: Best-effort delivery, no guarantees.
Level 1: Guaranteed delivery, multiple delivery possible.
Level 2: Guaranteed delivery, no multiple delivery

---------------

Three qualities of service for message delivery:
* "At most once", where messages are delivered according to the best
efforts of the underlying TCP/IP network. Message loss or duplication
can occur. This level could be used, for example, with ambient sensor
data where it does not matter if an individual reading is lost as the
next one will be published soon after.
* "At least once", where messages are assured to arrive but duplicates
may occur.
* "Exactly once", where message are assured to arrive exactly once.
This level could be used, for example, with billing systems where
duplicate or lost messages could lead to incorrect charges being
applied.

[Nicholas O'Leary]

Hi Zvi,

The spec says this about CleanSession:

>> If not set (0), then the server must store the subscriptions of the client after it disconnects. This includes continuing to store QoS 1 and QoS 2 messages for the subscribed topics so that they can be delivered when the client reconnects.
...
>> A non-clean session client will not miss any QoS 1 or QoS 2 messages that were published whilst it was disconnected. QoS 0 messages are never stored, since they are delivered on a best efforts basis.

I think that is quite clear that a broker is not expected to hold on to any QoS0 messages for a disconnected client.

Reading the section on QoS more generally, I agree the language needs to be more explicit about what the different levels mean. The table which contains the <=1/=1/>=1 does so without any context for what that notation means. It assumes the reader will know that represents how copies of the message can be expected.

Nick

> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt
>

[Zvi]

Nicholas,

thank you for explanation.
I see a need for additional QoS level between 0 and 1, let's call it
QoS 0b (or 3?)
It will be especially useful for reconnect cases, when you don't need
guaranteed delivery.
I.e. usually client have some reconnect logic, if socket disconnected
for some reason, sleep for short random time and reconnect. In this
case you don't need assured delivery, but still don't want to lose
messages (depends on queue size).

QoS Description
0 At most once Fire and Forget <=1 not queued
0b At most once Best Effort <=1 queued
with timeout
1 At least once Acknowledged delivery >=1 queued
2 Exactly once Assured delivery =1 queued

Zvi

> > To learn more about MQTT please visithttp://mqtt.org