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] Commented: (MQTT-27) Handling of the Dup Flag (section 2.1.2.1)


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

Peter Niblett commented on MQTT-27:
-----------------------------------

When the server is receiving a QoS 2 message, it seems clear that it should not propagate the DUP flag.  The transmission of the message from publishing client to server is independent of its transmission from the server to the subscribing clients. It's of no interest to those clients whether the message got to the server on the first attempt, or whether the publishing client had to resend it. This is in keeping with the current words in the WD08 spec which say that the DUP flag to indicates a resend of the MQTT PUBLISH control packet, not a resend of the application message that it contains.

Things are less clear-cut when the server receives a QoS 1 message. The server is at liberty to forward it on to its subscribed clients immediately before sending the PUBACK to the client. If it fails to complete this task, then the publishing client won't see the PUBACK and so at some stage it will resend the message with the DUP flag, and this will cause the server to attempt a resend to its subscribed clients. The worst case is one where the network fails while transmitting the PUBACK, or the publishing client fails before it has processed the PUBACK.  In this case all the subscribed clients will get a second copy of the message.   With the DUP flag defined as it is at present (indicating a resend of the PUBLISH Control Packet) all these subscribers would have DUP = 0 in their control packets, even though it's actually the second time they have seen this application message.

Our options are 

1. Keep the definition of DUP as it is - an indicator that the Publish packet is the second (or subsequent) attempt at sending the message by your immediate counterparty.  Update the non-normative note to  add a statement that the DUP flag does not refer to the application message, and that it's possible to get a second copy of the application message with DUP -= 0.

2. Change the semantics of DUP to say that it is an indicator that the application message contained in the PUBLISH packet might be a DUP.. This would require the server to set the DUP flag if there's any possibility that the application message could be a duplicate, in particular it should set the DUP bit when forwarding any message that it receives that has the DUP bit set,


The consensus on the "scrub call" was to go for option 1, so I will ad a proposal to that effect  

 



The arguments for and against propagating the DUP flag are as follows:

1. Reasons for propagating the DUP flag.

Suppoe
2. Reasons for not propagating the DUP flag

The DUP flag refers to (possible) redelivery at the MQTT transport level, not at the application message level. There are two transport steps involved (from client to server and then from server to client) and they should be viewed as independent. So DUP is :



> 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

        


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