[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=63781#comment-63781 ]
Peter Niblett commented on MQTT-286:
------------------------------------
I think Andy's point on Method B is that if the receiver has processed the message (giving it to its application if it's a client, or sending it on to others if it's a server) and then crashes before it has a chance to record this fact or send a PUBREC, then the sender will retransmit the original PUBLISH and it will be re-processed. PUBREL was originally conceived as a kind of Commit (in 2pc speak). You could make the same argument with regard to PUBREL/PUBCMP in Method A, and in both cases the implementation has to protect against it by writing its state to "stable storage" that can survive the crash, and coordinate that with the protocol so that it can do the right thing if it gets a repeat PUBLISH or PUBREL from the sender.
To my mind Method B is better, because we've still got the packetID as a kind of "Unit of Work" identifier. The receiver initiates a UoW against this id when it receives the first PUBLISH, and knows that any further PUBLISHes with that same id are repeats and so can be ignored. It can then prevent the sender from using that same id again by not sending the PUBCMP until it's finished the UoW. With Method A it doesn't start processing the UoW until it gets the PUBREL, so that means it would take longer before it can send the PUBCMP, leaving the id locked for longer. However I will defer to people who've actually implemented MQTT servers, as it might be that nobody really uses the packet ID in this way.
We've got two decisions to make here
1. Should we change the normative description in 4.3.3.2 in some way to make Method A not compliant with the spec? As I have said previously I don't think it's easy to do that in a rigorous way, and I also don't see there's a strong need to do it anyway.
2. Should we remove the description of method A from the picture? Unless there's something I am missing in my understanding. I can't see a good reason for keeping it. It might be possible to accommodate both, by changing the description of the receiver PUBLISH processing in the figure to say "Can initiate onward processing for this packetID"
One other point. We could consider adding the additional normative requirement that Ed mentioned..
"The receiver MUST NOT send more than one PUBREC for a single message arrival"
I think this is an invariant for both Method A and Method B.
> 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
> Components: core
> Affects Versions: 5
> Reporter: Ed Briggs
> Assignee: 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
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]