OASIS Message Queuing Telemetry Transport (MQTT) TCIcon indicating the project type

OASIS Message Queuing Telemetry Transport (MQTT) TC

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

Metadata: CONNECT and CONNACK Maximum Message Length

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      This was discussed in MQTT-276 (with notes from the F2F meetings) and has been tracked in MQTT-256 (Metadata).

      I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192:

      "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values."

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          6 older comments
          Hide
          Permalink
          edbriggs Ed Briggs [X] (Inactive) added a comment -

          We now have added 'reason strings' which can accompany any of the acknowledgements, and any of these strings could exceed the maximum packet size, which means just about anything can break.

          What I worry about is this. Suppose you have 1 million clients, and a programming error results in an oversize message getting sent to them all (say somebody decides to serialize a 'network timeout' exception call stack into an 'reason string'. ) We really want to prevent 1 million clients going into a reconnect/retry cycle.

          Show
          edbriggs Ed Briggs [X] (Inactive) added a comment - We now have added 'reason strings' which can accompany any of the acknowledgements, and any of these strings could exceed the maximum packet size, which means just about anything can break. What I worry about is this. Suppose you have 1 million clients, and a programming error results in an oversize message getting sent to them all (say somebody decides to serialize a 'network timeout' exception call stack into an 'reason string'. ) We really want to prevent 1 million clients going into a reconnect/retry cycle.
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          That would be bad... Did we agree in the end to allow clients to specify that they don't want to receive these strings on CONNECT? If we did, then clients could reconnect with such a flag set. However, they'd have to be able to identify this was the cause of the problem to start with...

          (As an aside your comment made me smile, as it reminded me of this from my childhood: https://www.youtube.com/watch?v=q3qfXpoScxw&feature=youtu.be&t=46 ).

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - That would be bad... Did we agree in the end to allow clients to specify that they don't want to receive these strings on CONNECT? If we did, then clients could reconnect with such a flag set. However, they'd have to be able to identify this was the cause of the problem to start with... (As an aside your comment made me smile, as it reminded me of this from my childhood: https://www.youtube.com/watch?v=q3qfXpoScxw&feature=youtu.be&t=46 ).
          Hide
          Permalink
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          mqtt-284 only added Reason Strings to CONNACK and DISCONNECT. The spec for these specifically says that these must not be sent if they cause the packet size to be greater than the MaxPacketSize.

          In mqtt-309 we propose adding Reason Strings to the various ACKs and I think we would need to put the same words there about the MaxPacketSize. In addition the proposal is to add a id/value on CONNECT which would limit the sending of this data. We could say that if the client requests "quiet" that no Reason String is send on any packet.

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - mqtt-284 only added Reason Strings to CONNACK and DISCONNECT. The spec for these specifically says that these must not be sent if they cause the packet size to be greater than the MaxPacketSize. In mqtt-309 we propose adding Reason Strings to the various ACKs and I think we would need to put the same words there about the MaxPacketSize. In addition the proposal is to add a id/value on CONNECT which would limit the sending of this data. We could say that if the client requests "quiet" that no Reason String is send on any packet.
          Hide
          Permalink
          edbriggs Ed Briggs [X] (Inactive) added a comment -

          Marking as resolved after discussion in TC on 6-October-2016. Editors will consolidate error handling in WD08 on MQTT-299, MQTT-300, and MQTT-301.

          Show
          edbriggs Ed Briggs [X] (Inactive) added a comment - Marking as resolved after discussion in TC on 6-October-2016. Editors will consolidate error handling in WD08 on MQTT-299 , MQTT-300 , and MQTT-301 .
          Hide
          Permalink
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          Issue included in MQTTv5.0 CS01 December 25, 2017

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - Issue included in MQTTv5.0 CS01 December 25, 2017

            People

            • Assignee:
              edbriggs Ed Briggs [X] (Inactive)
              Reporter:
              brianraymor Brian Raymor [X] (Inactive)
            • Watchers:
              5 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: