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

Disconnect semantics - add Sleep and Error packets

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MQTT-SN
    • Labels:
      None

      Description

      I was thinking about the description of the Disconnect packet, in particular the conformance statements I copied over from MQTT 5, such as: * After sending a DISCONNECT packet the sender MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection

      • After sending a DISCONNECT packet the Server MUST delete the Virtual Connection

      which do not apply when the Client is expecting a reply, which is usually (always?) when the Client is going to sleep. Also when going to sleep, the Virtual Connection is kept intact - the only case when sending a Disconnect that this is true.
       
      I am wondering therefore whether it would be better to have a SLEEP packet to be sent by a Client, with a corresponding SLEEPRESP response. This could allow:

      • making DiSCONNECT non-retransmissable again
      • never expecting a reply to a DISCONNECT
      • not needing Packet ID or Sleep Duration in the DISCONNECT (they would be on the Sleep packet)
      • making the DISCONNECT semantics much more like MQTT, including always deleting the Virtual Connection on sending a DISCONNECT
        P.S. Actually, do we still need a Packet ID in a DISCONNECT, for the case where it is a response to a request, say PUBLISH, but the receiver has no Virtual Connection, so the DISCONNECT is indicating that a new connection is needed? One way to avoid this would be to invent another packet explicitly for this purpose - ERROR or something like that.

        Attachments

          Activity

            People

            • Assignee:
              ian.craggs Ian Craggs
              Reporter:
              ian.craggs Ian Craggs
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: