[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=76962#comment-76962 ] Richard Coppen commented on MQTT-565: ------------------------------------- Reviewed with [~Andrew_Banks] and agreed to take this to the TC. The behaviour is explainable but the outcome where a shared subscriptions includes subscribers with different QoS is difficult to understand. One option might be to point this more clearly to raise implementer awareness. > 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]