[OASIS Issue Tracker] (MQTT-292) Modify statements about message ordering

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

    [ https://issues.oasis-open.org/browse/MQTT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63103#comment-63103 ] 

Ken Borgendale commented on MQTT-292:
-------------------------------------

For QoS=1, a re-published message is a separate message, most likely with a different packet ID.  This is the point of the first non-normative comment in section 4.6 and the reason it is non-normative is that a re-published QoS=1 message is a separate message from the original.  Sending the ACKs out of order thus has no affect of the message ordering of the forwarded messages, and on a client has no affect on the issue of whether the messages are presented to the client application in order.

For QoS=2 the sender is required to resend a PUBLISH in the original order.  As both sender and receiver keep state in this case and the re-publish uses the same packetID, it is possible to determine message order regardless of the order of the ACKs.  If messages a, b, and c are published, and the PUBREC for b is received, it certainly indicates that the receiver has received a as well, but the sender would republish since it has not received the PUBREC for a.  The alternative to the receiver sending the ACKs out of order is for the receiver to hold an ACK waiting for a previous ACK to be available.  Holding an ACK at the receiver rather than transmitting it does not enhance message ordering in any way, and causes issues for flow control.



> Modify statements about message ordering
> ----------------------------------------
>
>                 Key: MQTT-292
>                 URL: https://issues.oasis-open.org/browse/MQTT-292
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 5
>            Reporter: Ken Borgendale
>
> Section 4.6 message ordering has a number of imperatives which cause problems for large distributed severs but which do not give any value in terms of message ordering.
> The three ACK order mandatory normative statements (MQTT-4.6.0-2, MQTT-4.6.0-3, and MQTT-4.6.0-4) require that the ACKs be send back in the order of the publish. This is orthogonal to the messages being forwarded in order.  While this (when applied to servers) might be of value to clients, no client can realistically depend on them as they cannot know the configuration of the server (which is allowed to be configured to not ordered).  
> It would seem to make equal sense for a client to be allowed to process a topic unordered if so configured.
> There is a specific problem with ACK order at session recovery and when ACKs are sent as retry.
> The non-normative statements in the section should also be reworked.  The second one is clearly false.  Setting the in-flight window to 1 in no way guarantees the order of QoS=0 messages relative to QoS>0 messages.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)