[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-608) Add gateway retransmssion. and clarify client retransmission
[ https://issues.oasis-open.org/browse/MQTT-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Banks updated MQTT-608:
------------------------------
Proposal:
Replace...
4.14 Clientâs Publish Procedure
At any point in time a client may have only one QoS level 1 or 2 PUBLISH packet outstanding in each direction; i.e. it has to wait for the termination of this PUBLISH packet exchange before it could start a new level 1 or 2 transaction
Â
with...
A Client or Gateway processes a single outbound Qos 1 or Qos 2 message at a time.
This prevents retransmitted Qos 1 and Qos 2 messages from being received out of order.
A Client MUST NOT send a Qos 1 or Qos 2 PUBLISH packet with a new Application Message until it has received a PUBACK or PUBCOMP Packet with the Packet Identifier corresponding to the POUBLISH packet previously sent.
A Gateway MUST NOT send a Qos 1 or Qos 2 PUBLISH packet with a new Application Message until it has received a PUBACK or PUBCOMP Packet with the Packet Identifier corresponding to the POUBLISH packet previously sent.
Â
Replace...
4.18 Clientâs Retransmission Procedure
All packets that are âunicastedâ to the gatewayGW (i.e. sent using the gatewayGWâs unicast address and not broadcasted) and for which a gatewayGWâs reply is expected are supervised by a retry timer Tretry and a retry counter Nretry. The retry timer Tretry is started by the client when the packet is sent and stopped when the expected gatewayGWâs reply is received. If Tretry times out and the expected gatewayGWâs reply is not received, the client retransmits the packet. After Nretry retransmissions, the client aborts the procedure and assumes that the MQTT-SN gateway is no longer available. It should then try to connect to another gateway.
with...
4.18 Retransmission Procedure in the Client and Gateway
The Client or Gateway will start a retransmission retry timer, Tretry, when one of the following Packets is sent.
A Client MUST retransmit CONNECT, AUTH, REGISTER, PUBLISH Qos1, PUBLISH Qos2, PUBREL, SUBSCRIBE, UNSUBSCRIBE Packets, including a PROTECTION envelope if there is one, after Tretry has passed or close the Virtual Connection.
A Gateway MUST retransmit PUBLISH Qos1, PUBLISH Qos2, PUBREL Packets, including a PROTECTION envelope if there is one, after Tretry has passed or close the Virtual Connection.
The timer is cancelled if the corresponding acknowledgement packet is received. The Client or Gateway MUST retransmit the Packet after Tretry has passed or close the Virtual Connection.
If a Packet can be retransmitted it MUST NOT be sent using a Broadcast address.
If a Packet is retransmitted it MUST be identical to the previously transmitted Packet.
PUBLISH (used for QoS 0) and PUBLISH WITHOUT SESSION Packets MUST NOT be retransmitted.
If the Virtual Connection is closed, the protocol will restart when a new CONNECT packet flows from the Client.
Non normative comment.
The value of the retry interval TRetry is not specified by the protocol, however, to be useful it should be longer that the network round trip time. If it is excessively long, the time taken to detect and retransmit lost Packets will also be excessively long. Implementors should take care not to use a retry interval that might cause the network to become congested with retried Packets.
The PINGREQ packet described in {??3.1.22 PINGREQ??] can also be used to determine whether the virtual connection is alive.
An example of a retry algorithm is described in [???Appendix E.4???]
Reinstate the conformance clauses in ...
3.1.5.3 Connack Flags
If the Gateway accepts a connection with Clean Start set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a 0x00 (Success) Reason Code in the CONNACK packet [????].
If the Gateway accepts a connection with Clean Start set to 0 and the Gateway has Session State for the ClientID, it MUST set Session Present to 1 in the CONNACK packet, otherwise it MUST set Session Present to 0 in the CONNACK packet. In both cases it MUST set a 0x00 (Success) Reason Code in the CONNACK packet [????].
If the value of Session Present received by the Client from the Server is not as expected, the Client proceeds as follows:
 If the Client does not have Session State and receives Session Present set to 1 it MUST close the Virtual Connection [?????]. If it wishes to restart with a new Session the Client can reconnect using Clean Start set to 1.
 If the Client does have Session State and receives Session Present set to 0 it MUST discard its Session State if it continues with the Virtual Connection [????].
Â
If a Server sends a CONNACK packet containing a non-zero Reason Code it MUST set Session Present to 0 [?????].
was:
Replace...
4.14 Clientâs Publish Procedure
At any point in time a client may have only one QoS level 1 or 2 PUBLISH packet outstanding in each direction; i.e. it has to wait for the termination of this PUBLISH packet exchange before it could start a new level 1 or 2 transaction
Â
with...
A Client or Gateway processes a single outbound Qos 1 or Qos 2 message at a time.
This prevents retransmitted Qos 1 and Qos 2 messages from being received out of order.
A Client MUST NOT send a Qos 1 or Qos 2 PUBLISH packet with a new Application Message until it has received a PUBACK or PUBCOMP Packet with the corresponding Packet Identifier.
A Gateway MUST NOT send a Qos 1 or Qos 2 PUBLISH packet with a new Application Message until it has received a PUBACK or PUBCOMP Packet with the corresponding Packet Identifier.
Â
Replace...
4.18 Clientâs Retransmission Procedure
All packets that are âunicastedâ to the gatewayGW (i.e. sent using the gatewayGWâs unicast address and not broadcasted) and for which a gatewayGWâs reply is expected are supervised by a retry timer Tretry and a retry counter Nretry. The retry timer Tretry is started by the client when the packet is sent and stopped when the expected gatewayGWâs reply is received. If Tretry times out and the expected gatewayGWâs reply is not received, the client retransmits the packet. After Nretry retransmissions, the client aborts the procedure and assumes that the MQTT-SN gateway is no longer available. It should then try to connect to another gateway.
with...
4.18 Retransmission Procedure in the Client and Gateway
The Client or Gateway will start a retransmission retry timer, Tretry, when one of the following Packets is sent.
A Client MUST retransmit CONNECT, AUTH, REGISTER, PUBLISH Qos1, PUBLISH Qos2, PUBREL, SUBSCRIBE, UNSUBSCRIBE, WILLTOPICUPD, WILLMSGUPD Packets after Tretry has passed or close the Virtual Connection.
A Gateway MUST retransmit WILLTOPICREQ, WILLMSGREQ, PUBLISH Qos1, PUBLISH Qos2, PUBREL Packets after Tretry has passed or close the Virtual Connection.
The timer is cancelled if the corresponding acknowledgement packet is received. The Client or Gateway MUST retransmit the Packet after Tretry has passed or it can close the Virtual Connection.
If a Packet can be retransmitted it MUST NOT be sent using a Broadcast address.
If a Packet is retransmitted it MUST be identical to the previous Packet.
Non normative comment.
The value of the retry interval TRetry is not specified by the protocol, however, to be useful it should be longer that the network round trip time. If it is excessively long, the time taken to detect and retransmit lost Packets will also be excessively long.
Â
Reinstate the conformance clauses in ...
3.1.5.3 Connack Flags
If the Gateway accepts a connection with Clean Start set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a 0x00 (Success) Reason Code in the CONNACK packet [????].
If the Gateway accepts a connection with Clean Start set to 0 and the Gateway has Session State for the ClientID, it MUST set Session Present to 1 in the CONNACK packet, otherwise it MUST set Session Present to 0 in the CONNACK packet. In both cases it MUST set a 0x00 (Success) Reason Code in the CONNACK packet [????].
If the value of Session Present received by the Client from the Server is not as expected, the Client proceeds as follows:
 If the Client does not have Session State and receives Session Present set to 1 it MUST close the Virtual Connection [?????]. If it wishes to restart with a new Session the Client can reconnect using Clean Start set to 1.
 If the Client does have Session State and receives Session Present set to 0 it MUST discard its Session State if it continues with the Virtual Connection [????].
Â
If a Server sends a CONNACK packet containing a non-zero Reason Code it MUST set Session Present to 0 [?????].
> Add gateway retransmssion. and clarify client retransmission
> ------------------------------------------------------------
>
> Key: MQTT-608
> URL: https://issues.oasis-open.org/browse/MQTT-608
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: MQTT-SN
> Reporter: Andrew Banks
> Priority: Major
>
> The current specification describes the need for client retransmission in section 4.18,
> however there circumstances where the gateway will also need to retransmit packets.
> Â
> Discussion points.
> 1) There is little difference between sending PUBLISH Qos1 NRetry times and then stopping, and sending PUBLISH Qos 0?
> 2) Once a Qos2 PUBLISH has been sent the receiver may have stored state that it is obliged to keep until it has received PUBREL. MQTT states that
> in this case the sender MUST NOT apply Publication expiry if a PUBLISH packet has been sent, so that the receivers state is always deleted eventually.
> MQTT-SN needs to do something similar , so Nretry can't apply to Qos2 messages.
> 3) Clean start can be used by the Client to reset the protocol Session state if necessary. Session Present can be used by the Gateway
> to indicate that it has deleted the Session State. The client and Gateway already have a mechanism to close the Virtual Connection and restart
> with the Session state reset, so that NRetry would not be needed.
> 4) A retransmitted packet must be identical to the predecessor, otherwise it is ambiguous as to which version is being acknowledged. Is this OK with the Protection Envelope?
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]