Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-565

Shared subscription delivery behaviour where QoS differs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 5
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              coppen Richard Coppen (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: