OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (MQTT-102) What does QoS 0 mean? Should it be called "At Most Once"?


     [ http://tools.oasis-open.org/issues/browse/MQTT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Niblett updated MQTT-102:
-------------------------------

    Proposal: 
In WD 16
1. Remove the phrase "or duplication" from line 34 in the description of "At most once".
2. 2.1.21 (Editorial)  Split the para that starts at 469 into two non-normative comments  - or at least two separate paragraphs - as the first sentence (469) is different (in fact the converse) to the point that is covered in line 470-473.
3. Reword the paragraph in 3.8.4 that starts at line 1150.
Existing text:
A SUBACK Packet MUST be sent to the Client by the Server containing a return code for each Topic Filter/QoS pair [MQTT-3.8.4-4]. The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server [MQTT-3.8.4-5].

Replacement text:
The SUBACK Packet sent by the Server to the Client MUST contain a return code for each Topic Filter/QoS pair showing the maximum QoS (if any) that was granted for that Subscription  [MQTT-3.8.4-4]. The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server. The server is permitted to send duplicate copies of a message to a subscriber in the case where the original message was published with QoS 1 and the maximum QoS granted was QoS 0.[MQTT-3.8.4-5].

4. Replace the first non-normative comment that starts at line 1157
Existing text:
Non-normative comment.
For example, if a subscriber has requested QoS 1 for a particular Topic Filter, then a QoS 0 Message matching the filter is delivered to the Client at QoS 0. A QoS 2 Message published to the same topic is downgraded by the Server to QoS 1 for delivery to the Client.

Replacement text:
Non-normative examples:

If a subscribing Client has been granted maximum QoS 1 for a particular Topic Filter, then a QoS 0 Application Message matching the filter is delivered to the Client at QoS 0. This means that at most one copy of the message is received by the Client. On the other hand a QoS 2 Message published to the same topic is downgraded by the Server to QoS 1 for delivery to the Client, so that Client might receive duplicate copies of the Message. 

If the subscribing Client has been granted maximum QoS 0, then an Application Message originally published as QoS 2 might get lost on the hop to the Client, but the Server should never send a duplicate of that Message. A QoS 1 Message published to the same topic might either get lost or duplicated on its transmission to that Client. 

  was:
In WD16 

Remove the phrase "or duplication" from line 34 in the description of "At most once".

Add to section 2.1.2.1 Dup 

Non Normative comment 
The Server will send an outbound PUBLISH Packet for each inbound PUBLISH packet that matches a subscription. Consequently, a duplicated inbound PUBLISH Packet will result in several outbound PUBLISH Packets.


Apologies for the typo in my previous comment. I have updated the proposal to match what I intended to say.

> What does QoS 0 mean? Should it be called "At Most Once"?
> ---------------------------------------------------------
>
>                 Key: MQTT-102
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-102
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Peter Niblett
>             Fix For: 3.1.1
>
>
> WD 14 lines 34, 378 and 1254  all refer to QoS 0 as "At most once" (in contrast to QoS 1 which is "At least once", and QoS 2 "Exactly once").  Line 35 goes on to state that for QoS 0 "Message loss or duplication can occur".   However the description of QoS 0 section 4, line 1256 says "The message arrives at the receiver either once or not at all".
> The inclusion of "duplication" in the statement in 35 causes two problems:
> 1. It looks like a mistake to refer to something as "At most once" and at the same time tell people that duplication can occur
> 2. It gives equal status to loss and duplication. Someone implementing (for example) a server or a bridge from another protocol can find themselves in a position where they have a QoS 0 message which might possibly have already been sent. What should they do?  Should they assume that consumers don't care about duplicates and so they should send it just in case, or can they say that consumers don't care about lost messages, so they should discard it ?
> We need to clarify this ambiguity and decide what QoS 0 really means
> a) It really does mean "At most once", in which case we remove the word duplication from 35. We should also add some normative text to say that a sender  should never knowingly send a QoS 0 message that might be a duplicate (i.e. it should err on the side of dropping a message rather than possibly sending a duplicate).
> b) It really does mean "Duplicates and Gaps" (so taken to an absurd extreme a server that continually published message 1 ad infinitum would be compliant). In this case we should stop referring to it as "At most once".
> At risk of complicating things, I would like to add a related point to be considered alongside this issue, and that is the requirement on the use of the DUP flag in QoS 1.  In WD14 line 363 there's a statement that says
> "If Dup -0 then the flow is the first occasion that the client or server has attempted to send the MQTT PUBISH (sic) packet" If DUP 1 then this indicates that the flow might be a re-delivery of an earlier packet".  
> It has been pointed out that a client that always sets DUP 1 would be compliant with this statement, which I am sure was not our intention. I think the statement should be reworded in normative language to say that you MUST set DUP 0 on the first occasion that a packet ID is used, and DUP 1 if you have attempted to send a message with that packet ID previously.. (the precise wording of this would need some work) 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]