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

Common method for handling limits violations.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Resolution:
      Hide

      Incorporated into the underlying issues:

      MQTT-301 Metadata: CONNACK Retained messages supported
      MQTT-300 Metadata: CONNACK Maximum QoS
      MQTT-299 Metadata: CONNECT and CONNAC Maximum message length.

      Show
      Incorporated into the underlying issues: MQTT-301 Metadata: CONNACK Retained messages supported MQTT-300 Metadata: CONNACK Maximum QoS MQTT-299 Metadata: CONNECT and CONNAC Maximum message length.

      Description

      I'd like to propose a common error handling methodology for
      violation of the limits set out in:

      MQTT-301 Metadata: CONNACK Retained messages supported
      MQTT-300 Metadata: CONNACK Maximum QoS
      MQTT-299 Metadata: CONNECT and CONNAC Maximum message length.

      Any violation of these limits should result in the flow of a CONNACK
      or DISCONNECT packet by the receiver with a return code indicating
      a protocol violation or a more explicit return code followed by network disconnection.

      This is along the same lines of the approach set out in
      MQTT-310 Treat invalid topic alias as a protocol error.

      The rationale is as follows.

      Continuing the protocol is going to result in data loss of some form.
      This especially problematic if a following packet relies on the delivery
      of an earlier one. This is the case for both the middleware and the application.

      It is better that the sender applies the limits rather than
      ignoring them and relying on the behaviour of the receiver.
      Defining the behaviour where some packet processing has failed will
      make the protocol more complex and variants of the behaviour might emerge. Applications would start to rely on the variants.

      Where the client writes ahead before it receives CONNACK, it knows that it is taking a risk.
      It can mitigate the risk by not using Will messages, not publishing retained messages,
      using only short payloads and Qos=0.

      The sender is able to react to the limit. For example a client implementation can inform its
      app that a packet is too big rather than sending it. Similarly a server
      could disconnect its client rather than sending a packet that is larger than the client
      wants to receive. This is preferable to having the application writer
      model all of the possibilities of what might happen to his messages
      if limits are violated. Especially where the violation happens later after a chain of sub sub steps.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew_Banks Andrew Banks
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: