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

CONNACK to contain session present indication

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MQTT-SN
    • Labels:
      None
    • Proposal:
      Hide

      1.1.1 CONNACK

       
      (SEE SCREENSHOT FOR TABLE)
       
      Table 16: CONNACK packet

      The CONNACK packet is sent by the Gateway in response to a connection request from a client.

      1.1.1.1 Length & Packet Type

      The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Please refer to section 2.1 for a detailed description.

      1.1.1.2 Reason Code

      Byte 3 in the CONNACK header contains the Connect Reason Code. If a CONNECT packet is received by the Server, the Server will send a CONNACK packet containing the appropriate Reason code from the table below.

       

      Value Hex Reason Code name Description
      0 0x00 Success The Connection is Accepted
      1 0x01 Congestion The Server notification that it is experiencing congestion 
      3 0x03 Not supported The CONNECT packet has provided information that is not supported by the protocol
      132 0x84 Unsupported protocol version The Server does not support the version of the MQTT protocol requested by the Client.

      Table 17: CONNACK Reason Codes values

      1.1.1.3 Connack Session Flags

      The Connack Flags is 1 byte field which contains parameters specifying the behavior of the MQTT-SN connection on the gateway.

      The Connack Flags field includes the following flags:

      • Session Present: Stored in Bit 0 and specifies whether an existing session was present on the gateway for the given clientId

       

      The Gateway MUST validate that the reserved flags in the CONNACK packet are set to 0. If any of the reserved flags is not 0 it is a Malformed Packet.

      1.1.1.4 Session Expiry Interval

      If the Session Expiry Interval is 0, the value in the CONNECT Packet used. The server uses this property to inform the Client that it is using a value other than that sent by the Client in the CONNACK.

      1.1.1.5 Assigned Client Identifier

      The Client Identifier assigned by the gateway when the associated CONNECT packet contained no Client Identifier. If the Client connects using a zero length Client Identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Gateway.

       

      The Assigned Client Identifier MUST be a UTF-8 Encoded String.

       

       

      Show
      1.1.1 CONNACK   (SEE SCREENSHOT FOR TABLE)   Table 16: CONNACK packet The CONNACK packet is sent by the Gateway in response to a connection request from a client. 1.1.1.1 Length & Packet Type The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Please refer to section 2.1 for a detailed description. 1.1.1.2 Reason Code Byte 3 in the CONNACK header contains the Connect Reason Code. If a CONNECT packet is received by the Server, the Server will send a CONNACK packet containing the appropriate Reason code from the table below.   Value Hex Reason Code name Description 0 0x00 Success The Connection is Accepted 1 0x01 Congestion The Server notification that it is experiencing congestion  3 0x03 Not supported The CONNECT packet has provided information that is not supported by the protocol 132 0x84 Unsupported protocol version The Server does not support the version of the MQTT protocol requested by the Client. Table 17: CONNACK Reason Codes values 1.1.1.3 Connack Session Flags The Connack Flags is 1 byte field which contains parameters specifying the behavior of the MQTT-SN connection on the gateway. The Connack Flags field includes the following flags: Session Present: Stored in Bit 0 and specifies whether an existing session was present on the gateway for the given clientId   The Gateway MUST validate that the reserved flags in the CONNACK packet are set to 0. If any of the reserved flags is not 0 it is a Malformed Packet. 1.1.1.4 Session Expiry Interval If the Session Expiry Interval is 0, the value in the CONNECT Packet used. The server uses this property to inform the Client that it is using a value other than that sent by the Client in the CONNACK. 1.1.1.5 Assigned Client Identifier The Client Identifier assigned by the gateway when the associated CONNECT packet contained no Client Identifier. If the Client connects using a zero length Client Identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Gateway.   The Assigned Client Identifier MUST be a UTF-8 Encoded String.    

      Description

      Submitted By: Patrick van Bennekom

       

      Currently I’m working on a MQTTSN project (both client and gateway). We have MQTTSN running on an embedded environment making use of a proprietary communication bus with low bandwidth.

      For this constrained network we try to keep reconnects / and resubscriptions to a minimum by using the cleansession flag.

       

      In MQTT we get notified via the status byte of the CONNACK if the broker already has a session stored for our client, this feature is very convenient after a reset of the embedded client or after a restart of the broker and can be used to determine the difference between a communication glitch (a few missing packets) or a new connection (crash/reset of the broker).

       

      However, it doesn’t seem that MQTTSN has a way of informing us of the sessionPresentflag. This has caused some challenges in our setup where we try to reconnect after a failed publish with cleansession=0 after the broker had reset. The broker informs the MQTTSN-GW of the missing session, but the MQTTSN-GW has no way of providing this information to the client. This left us in a state where we can publish messages, as the GW did remember our topics, but would never receive a subscription because the broker no longer has them stored.

       

      I’m following the development of MQTTSN V2.0 and to my surprise I saw a new RC code: 0x05 Rejected: no session. Unfortunately, this RC is only used for the disconnect message. Why is this not extended to the connect message to inform the client that no active session was currently found on the broker?

       

      Is there another way you plan to incorporate the cleansession/sessionpresent flow in MQTTSN? I think this is a great feature for constrained devices/networks as otherwise we would have to connect cleanly (with all subscriptions) for every communication error.

       

       

       

      ========================

       

      The sub-committee agreed this was a good candidate for inclusion in STC call 17/12/2021.

       

      Agreed to draft 2 proposals for discussions;

       

      1) 2 new return codes (SUCCESS_SESSION_PRESENT | SUCCESS_SESSION_NOT_PRESENT)

      2) new field "Session Present".

       

      For discussion.

        Attachments

          Activity

            People

            • Assignee:
              simon.johnson1 Simon Johnson [X] (Inactive)
              Reporter:
              simon.johnson1 Simon Johnson [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: