[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-565) Shared subscription delivery behaviour where QoS differs
[ https://issues.oasis-open.org/browse/MQTT-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=77192#comment-77192 ] Richard Coppen commented on MQTT-565: ------------------------------------- Reviewed on TC call 22.06.2020  Outcome: It wouldn't be normal client behaviour to discard a session in the middle of a QoS exchange. QoS is a property of the subscription and not the share. The advice to subscribers would be not to mix QoS in a given share. Where QoS values are mixed in a share the processing QoS is set to the QoS of the first subscription match. The spec describes that the matching subscriber's QoS is honoured.  However, it is unclear to implementors what is intended here. Candidate non-normative comment for a future errata or as a section in implementors notes  Thanks toÂTakatoshi for raising this.  > Shared subscription delivery behaviour where QoS differs > -------------------------------------------------------- > > Key: MQTT-565 > URL: https://issues.oasis-open.org/browse/MQTT-565 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: Bug > Components: core > Affects Versions: 5 > Reporter: Richard Coppen > Priority: Major > > Comment fromÂTakatoshi on MQTT comments list > I have a question about Shared Subscritions. > > In 4.8.2 Shared Subscriptions > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oasis-2Dopen.org_mqtt_mqtt_v5.0_os_mqtt-2Dv5.0-2Dos.html-23-5FToc3901250&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=HFOYf-FWdPMlPq2g5pc8M7HUYiSp2sC9P2hDoZdjdRo&m=n9Lr__8q3-_IUeX0hPXa8E8WDT03yjgYr1cGDV-rcdU&s=QasW28pSWOMwxYmNiXVKaK6uvdmrWOlPtHWqUZGVTig&e= > , > > The spec said that as follows: > > --- > >     If the Server is in the process of sending a QoS 2 message > to its chosen subscribing Client and the connection to the Client > breaks before delivery is complete, the Server MUST complete the > delivery of the message to that Client when it reconnects > [MQTT-4.8.2-4] as described in section 4.3.3. If the Client's Session > terminates before the Client reconnects, the Server MUST NOT send the > Application Message to any other subscribed Client [MQTT-4.8.2-5]. > >     If the Server is in the process of sending a QoS 1 message > to its chosen subscribing Client and the connection to that Client > breaks before the Server has received an acknowledgement from the > Client, the Server MAY wait for the Client to reconnect and retransmit > the message to that Client. If the Client'sSession terminates before > the Client reconnects, the Server SHOULD send the Application Message > to another Client that is subscribed to the same Shared Subscription. > It MAY attempt to send the message to another Client as soon as it > loses its connection to the first Client. > > --- > > What happened the following case ? > > Client A: Session Expiry Interval 10 seconds, SUBSCRIBE $share/sn1/t1 QoS 1 > Client B: Session Expiry Interval 10 seconds, SUBSCRIBE $share/sn1/t1 QoS 2 > > A broker use a round robin algorithm. The next target is Client A. > > 1. Publisher send a message to t1 and its QoS is 2. > 2. The broker send PUBLISH the message to Client A. > 3. Client A disconnected before send PUBACK. > 4. The broker set 10 seconds timer to expirer (terminate) the Session > for Client A. > 5. The timer is fired (before Client A reconnects). > > The broker SHOULD send the message to the Client B ? > > Consider another case.The next target is Client B. > > 1. Publisher send a message to t1 and its QoS is 2. > 2. The broker send PUBLISH the message to Client B. > 3. Client B disconnected before send PUBREC. > 4. The broker set 10 seconds timer to expirer (terminate) the Session > for Client B. > 5. The timer is fired (before Client B reconnects). > > The broker MUST NOT send the message to the Client A ? > > It is weird for me that the broker's behavior is different. It depends > on the delivery target QoS. > > Am I missing something ? > > I personally think that if the delivery target is decided once, > delivery target shouldn't be changed even if the Session is > terminated. > That is QoS2 behavior. If QoS1 is the same, it is simple. > > Why the behavior of QoS1 and QoS2 are diffferent ? > > Thanks, > Takatoshi -- 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]