-
Type: Task
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: MQTT-SN
-
Labels:None
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.