[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=63783#comment-63783 ] Ed Briggs commented on MQTT-286: -------------------------------- I think what we're pondering here is 'partial loss/corruption of state'. The safe-store of the message and the protocol state may fail independently (e.g. message is stored, protocol value not stored leading to duplication - or vice versa). In one case, the message is duplicated. In the other the sender believes the message was successfully delivered at QoS 2 when it was not. Neither of these is acceptable from a correctness standpoint. I think these considerations are beyond the scope and capabilities of the client <-> server delivery protocol which seeks to recover lost and truncated messages in the event of transport failures. (Just for clarification, if the Method B receiver crashes before sending a PUBREC (but after forwarding) there is no duplication, the sender will resend and the PUBREC will be re-issued without causing a duplicate delivery. It is ONLY in the case that the protocol state has been lost but the message has been forwarded that this will occur.) (Also for clarification: "The receiver MUST NOT send more than one PUBREC for a single message arrival", this is intended to prevent a message from being both NAKed and Acked. The TC agreed to this because it was shown doing so would permit arbitrary re-ordering of messages at QoS 2.) > 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]