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] (MQTT-286) Make Qos 2 Delivery Method 'B' Normative

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

Ken Borgendale commented on MQTT-286:

The QoS=2 flow can be thought of as a simplified global transaction containing a single message and just two participants.  It is possible for either the sender or receiver to extend the transaction to other participants.  In these terms, Option A makes the sender the transaction manager, and Option B makes the receiver the transaction manager. The current spec leaves which is the transaction manager up to the receiver.  Therefore the sender cannot optimize any case of the QoS=2 flow, but the receiver can do so by using option B.  Indeed as shown in Ed's paper, the only rational thing for the receiver to do is to immediately process the message (prepare and commit) when it receives the PUBLISH, and just do the forget when it receives the PUBREL.

With either option the sender must have completed the prepare before doing the PUBLISH, and the receiver must complete the prepare before sending the PUBREC.  Thus from a functional standpoint (as opposed to performance) the results should be the same.  

While I agree that nothing is gained by having these two options, I do have a problem with the proposed text.  "If the forwarding operation fails, the receiver MUST send an appropriate error response, or terminate the transport as specified in section {TBD part of MQTT-236 }".  The QoS flow is defined only a single transport link, and thus the receiver responds with any errors it has in receiving the message and persisting it as required (prepare).  If it accepts the message this is not a guarantee of any subsequent onward delivery.  Such processing may in fact occur as a totally asynchronous process and far in the future.  Thus I think the correct text would be:  "If the receive of the message fails, the receiver MUST send an appropriate error response, or terminate the transport".

> Make Qos 2 Delivery Method 'B' Normative
> ----------------------------------------
>                 Key: MQTT-286
>                 URL: https://issues.oasis-open.org/browse/MQTT-286
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>            Reporter: Ed Briggs
> I propose QoS 2 Delivery Method B should become the only forwarding method, and Method A be eliminated in future MQTT versions.
> This can reduce delivery delays for PUBLISH messages over QoS 2 flows when the network propagation delay is substantial. In addition, Method B eliminates temporary storage required by Method A.  Both methods are described in MQTT 3.1.1 Section 4.3.3 in non-normative text accompanying diagram 4.3.
> This change may also be beneficial for the following MQTT isses:
> MQTT-197  Support Request Reply
> MQTT-236  Consolidate ACKs, Enable NAKs
> MQTT-271  Describe Small Device Limitations aka The Arduino problem.
> I propose the existing non-normative text in section 4.3.3 : 
>  "...there are two methods by which QoS 2 can be handled by the receiver. They differ in the point within the flow at which the message is made available for onward delivery. The choice of Method A or Method B is implementation specific. As long as an implementation chooses exactly one of these approaches, this does not affect the guarantees of a QoS 2 flow."
> Be replaced by normative text along the lines of the following:
> "Upon receiving a QoS 2 PUBLISH message which is both valid and not a duplicate, the receiver SHOULD immediately initiate onward delivery and send a PUBREC. The receiver MAY send a PUBREC before the onward delivery is complete.  If the forwarding operation fails, the receiver MUST send an appropriate error response, or terminate the transport as specified in section {TBD part of MQTT-236 }. The receiver MUST NOT send more than one PUBREC for the a single message arrival."
> A brief containing additional details can be found here:
> https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/58364/Mqtt-286-MqttQoS2DeliveryProposal.pdf

This message was sent by Atlassian JIRA

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