[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:comment-tabpanel&focusedCommentId=84301#comment-84301 ] Davide Lenzarini edited comment on MQTT-608 at 2/15/24 12:51 PM: ----------------------------------------------------------------- "_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._" [~AndrewBanks]ÂI would propose the following changes * "A Client MUST NOT send a {color:#de350b}*new* {color}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 *{color:#de350b}of the one previously sent to the same Gateway{color}*." * "A Gateway MUST NOT send a *{color:#de350b}new{color}* 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 *{color:#de350b}of the one previously sent to the same Client{color}*."  was (Author: davide.lenzarini): "_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._" [~AndrewBanks] Should we say * "A Client MUST NOT send a {color:#de350b}*new* {color}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 *{color:#de350b}of the one previously sent to the same Gateway{color}*." * "A Gateway MUST NOT send a *{color:#de350b}new{color}* 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 *{color:#de350b}of the one previously sent to the same Client{color}*."  > 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]