[OASIS Issue Tracker] (MQTT-565) Shared subscription delivery behaviour where QoS differs

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ 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)