Hi Paul,
the subject is fine. The spec says:
"A server or gateway may also send a DISCONNECT to a client, e.g. in
case a gateway, due to an error, cannot map a received message to a
client. Upon receiving such a DISCONNECT message, a client should
try to set up the connection again..."
I envisage an MQTT-SN gateway sending DISCONNECT packets to all
connected clients in the event of shutting down.
Also, if there are any other return codes that should be defined,
that is a comparatively small change, compared to MQTT where there
are currently no return codes for publish!
Ian
On 10/28/2015 01:52 PM, Paul Kierstead
wrote:
Lets say the GW has been power cycled, crashed or,
for that matter, rebuilt. The client sends a PUBLISH, or perhaps
even a PING. How can the gateway inform the client that it is
not connected? The return codes for publish do not seem to allow
for a "I don't know who the hell you are" code. I guess, in the
case of PING, the gateway could just decline to answer, and
eventually the client would get the idea. If the client is
primarily a subscriber, it would be worse; it could basically
wait there for ever for a publish that is not forth coming. In
theory it would ping the gateway for keep-alive, and it would
get back to the above ping response. I suspect there is
something I've glossed over in the protocol.
My apologies if a protocol discussion doesn't fit into
'dev'; I wasn't sure.
PK
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|
