[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-208) confusing narrative around redelivery of control packets
[ https://tools.oasis-open.org/issues/browse/MQTT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Coppen updated MQTT-208:
--------------------------------
Proposal:
Update Section 4.4 as follows:
Remove
>>
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Clients MAY re-send SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but are not REQUIRED to do this.
While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt redelivery of unacknowledged packets at other times. However, redelivery is not encouraged unless a network failure has been detected.
The PUBLISH packet MUST have the DUP flag set to 1 when it is re-sent [MQTT-4.4.0-2].
Non Normative comment.
Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.
<<
Replace with:
>>
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.
Non Normative comment.
Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.
<<
Note: the clause "The PUBLISH packet MUST have the DUP flag set to 1 when it is re-sent [MQTT-4.4.0-2]." is a dup of "The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH Packet [MQTT-2.2.2-3]." under Section 2.2.2.1. Removing it from 4.4 seems to make sense.
was:
Remove:
While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt redelivery of unacknowledged packets at other times. However, redelivery is not encouraged unless a network failure has been detected.
Adjust the following para 4.4:
...This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Clients MAY resend SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but are not REQUIRED to do this. >> Redelivery of Control Packets at any other time is discouraged and should not be necessary on modern network transports. <<
> confusing narrative around redelivery of control packets
> --------------------------------------------------------
>
> Key: MQTT-208
> URL: https://tools.oasis-open.org/issues/browse/MQTT-208
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: core
> Reporter: Richard Coppen
>
> Section 4.4 is slightly confusing with respect to Control Packet redelivery - the suggestion is that all packets can be retried. 3.1 CONNECT states that a second flow of CONNECT is not allowed.
>
--
This message was sent by Atlassian JIRA
(v6.1.1#6155)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]