[OASIS Issue Tracker] Commented: (MQTT-27) Handling of the Dup Flag (section 2.1.2.1)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/MQTT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33847#action_33847 ] 

Raphael Cohen commented on MQTT-27:
-----------------------------------

This is quite a grey area - whatever we say should be tightly defined, but try to avoid asking clients or brokers to do too much.

My current personal interpretation was that DUP=1 was effectively defining a re-delivery attempt. That's quite a different thing from annotating a duplicate message from client to receiver - the lifetimes are quite different. But it can also be argued the opposite way. For instance, it could be argued that that interpretation does not sit easily with other areas in the spec - such as the use of QoS being propagated.

If DUP is re-delivery, then its handling should be at the discretion of a receiver. Only a receiver will know if it has seen the message before or not, or received part of it, etc. However, if we went with the second sentence of (2), then it gets quite interesting. There can then be DUPs of DUPs, effectively.

The DUP flag could also be seen to be overlapping in meaning with QoS for some scenarios - particularly (3), where one could be seen to be making a statement as a receive about the desirability of at-least-once messaging.

It might be worth approaching this as thinking about how it might map to JMS or OpenMAMA, say, simply to get a feel for how client code might handle it.

My summary: I'd prefer that DUP is simply reflecting a delivery-attempt, and is scoped to the duration of the interaction of the connection's 2 parties - ie it is persistent if the connection is disconnected and reconnected (perhaps with a nod towards its interaction with QoS) but not from client -> broker / bridge -> client. That delivery attempt should be counted as for those two parties, ie delivery attempts to other parties don't count (eg when there are several subscribers to a broker).

Open to other views...


> Handling of the Dup Flag (section 2.1.2.1)
> ------------------------------------------
>
>                 Key: MQTT-27
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-27
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Peter Niblett
>
> WD04, lines 295-297 contain a non-normative comment that says
> "If 1, the recipient might have previously received the message, it shuld not treat this flag as an indication that it has previously received the MQTT Command message and should not use the DUP flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface."
> There is a typo "shuld", and the use of two different terms "message and MQTT Command message" which I think mean the same thing. However we haven't really defined the role of recipient or "its application" and in addition it made me notice that we don't say anything normatively about how the server should handle an incoming Control Packet that contains the DUP flag.  
> I think what the current non-normative words are trying to say is that when a recipient receives a Control Packet with the DUP flag set to 1, it should not assume that it has previously seen that Control Packet, just because the DUP flag is set.  It might not have received the original copy at all, or it might have received it but had failed before it had managed to do much processing of the message. 
> Do we need further normative words?
> 1. The specification should not dictate how a receiving client library handles its relationship with its application, so no more words are needed here. A client library might choose to dedup its incoming  PUBLISH messages, or might simply hand them off to the application with the DUP flag set.
> 2. Similarly we should not say exactly how the server handles incoming PUBLISH messages which have the DUP flag set to 1. However if it does decide to deliver the message to one or more subscribers, how does it set the DUP flag in those messages? Does it set it to 0 for the first attempt, or does it set it to 1 on all attempts? I think that's something which should be normatively specified.
> 3. Are there any special semantics relating to a SUBSCRIBE with DUP = 1?

-- 
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