Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: No Action
    • Affects Version/s: 5, CSD01
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      Line 2111: Table 3-5 - PUBACK Reason Codes
      need to add code value 150 (0x96) "Message rate too high" to the table.

      Line 881: Table 2-4 Reason Codes
      add PUBACK in the Packets column for Value 150 (0x96) "Message rate too high"

      This code is different than return code 151 and needed for PUBACK, to inform the Sender that it has temporarily exceeded the throughput limit (vs. the cumulative (daily/monthly) quota for a customer, represented by value 151).

      Example: Sender can wait for a period of time and then continue sending messages, instead of forcing it to disconnect and perform a resource intense reconnect.

      This issue was originally reported in MQTT-417, which doesn't seem to be applied in WD14.

        Attachments

          Activity

          Hide
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          The thought was that for QoS>0 messages the message rate can be limited using flow control, and for QoS=0 messages there is no PUBACK or PUBREC to return such a return code. Thus the 0x96 (Message rate too high) is only a disconnect.

          Do we want to describe two mechanisms for flow control of QoS>0 messages?

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - The thought was that for QoS>0 messages the message rate can be limited using flow control, and for QoS=0 messages there is no PUBACK or PUBREC to return such a return code. Thus the 0x96 (Message rate too high) is only a disconnect. Do we want to describe two mechanisms for flow control of QoS>0 messages?
          Hide
          andrew_banks Andrew Banks (Inactive) added a comment -

          Agreed to defer in TC meeting June 22nd.

          Show
          andrew_banks Andrew Banks (Inactive) added a comment - Agreed to defer in TC meeting June 22nd.
          Hide
          kdot Konstantin Dotchkoff [X] (Inactive) added a comment -

          In the TC meeting on September 28th the TC decided:

          • DISCONNECT can be used with the appropriate error code.
          • for QoS > 1 the receiver may decide to delay PUBACKs to throttle down the send rate if appropriate.

          The TC decided to close this issue with no need for changes to the spec.

          Show
          kdot Konstantin Dotchkoff [X] (Inactive) added a comment - In the TC meeting on September 28th the TC decided: DISCONNECT can be used with the appropriate error code. for QoS > 1 the receiver may decide to delay PUBACKs to throttle down the send rate if appropriate. The TC decided to close this issue with no need for changes to the spec.
          Hide
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          Discussed at the 2017-09-28 MQTT TC. The decision was to close this issue without making any change.

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - Discussed at the 2017-09-28 MQTT TC. The decision was to close this issue without making any change.

            People

            • Assignee:
              Unassigned
              Reporter:
              kdot Konstantin Dotchkoff [X] (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: