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

Flowing MQTT messages before CONNACK is received in the client.

    XMLWordPrintable

    Details

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

      MQTT Client

    • Proposal:
      Hide

      MQTT Clients are allowed to send MQTT command packets immediately after sending a CONNECT packet, clients do not need to wait for a CONNACK
      packet to arrive from the server. If the server rejects the CONNECT, either by closing the TCP session or by flowing a CONNACK packet with a non zero return code and then disconnecting the TCP session it MUST NOT process any data sent by the client after the CONNECT packet.

      Non Normative comment.

      If the client exploits its freedom to send MQTT command packets before it receives a CONNACK,
      it might simplify the client implementation, because it does not have to police the connected state.
      Secondly the client might achieve a lower latency connection, because the client does not have to wait for the CONNACK
      to be received before it proceeds to send other command packets.
      The client accepts that any data that it sends before it receives a CONNACK packet from the server
      will not be processed if the server rejects the connection.

      Show
      MQTT Clients are allowed to send MQTT command packets immediately after sending a CONNECT packet, clients do not need to wait for a CONNACK packet to arrive from the server. If the server rejects the CONNECT, either by closing the TCP session or by flowing a CONNACK packet with a non zero return code and then disconnecting the TCP session it MUST NOT process any data sent by the client after the CONNECT packet. Non Normative comment. If the client exploits its freedom to send MQTT command packets before it receives a CONNACK, it might simplify the client implementation, because it does not have to police the connected state. Secondly the client might achieve a lower latency connection, because the client does not have to wait for the CONNACK to be received before it proceeds to send other command packets. The client accepts that any data that it sends before it receives a CONNACK packet from the server will not be processed if the server rejects the connection.
    • Resolution:
      Hide

      Fixed in Draft07 lines 462 on.

      Show
      Fixed in Draft07 lines 462 on.

      Description

      The MQTT Client sends CONNECT and receives CONNACK in response. Should the client have to wait for the CONNACK or is it free to send other commands before it receives the CONNACK?

      The advantages of allowing the client to proceed before receiving the CONNACK are:
      1) Simpler client implementation, because the API does not have to police the connected state.
      2) Lower latency because the client application does not have to wait for the CONNACK.

        Attachments

          Activity

            People

            • Assignee:
              andrew_banks Andrew Banks (Inactive)
              Reporter:
              andrew_banks Andrew Banks (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: