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

MQTT 3.1.1 Session Take Over and Will Message Delivery



    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.1
    • Component/s: edits
    • Labels:
    • Environment:

      MQTT 3.1.1

    • Resolution:

      Closing as duplicate of MQTT-262

      Closing as duplicate of MQTT-262


      Ed Briggs Reported -

      The specification does not seem to specify if the will message should be delivered as a consequence of session take-over. (i.e. due to a second connection with the same client id)
      From the specification: "Section

      478 Situations in which the Will Message is published include, but are not limited to:
      479 - An I/O error or network failure detected by the Server.
      480 - The Client fails to communicate within the Keep Alive time.
      481 - The Client closes the Network Connection without first sending a DISCONNECT Packet.
      482 - The Server closes the Network Connection because of a protocol error."

      Later, in the table of Mandatory Normative Statements, it states the requirements a bit differently:

      [MQTT-3.1.2-8] Mandatory Normative Statements (Page 71, no line numbers)

      " ... The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet."

      It isn’t clear what the correct behavior should be when session take-over occurs. There are several other confusing aspects to interpreting the normative text:

      • the term 'protocol error' appears only on line 482 (above) and is not defined.
      • the term 'protocol violation' is defined, but session eviction is not defined as a protocol violation.

      I spotted this while investigating the session behavior in connection with proposed 'server initiated disconnect messages'.I wonder if this might need to be clarified in the MQTT 3.1.1 specification, even in the form of non-normative text.




            • Assignee:
              edbriggs Ed Briggs [X] (Inactive)
              ragupta2 Rahul Gupta
            • Watchers:
              4 Start watching this issue


              • Created: