mqtt-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [mqtt-comment] WILL publishing clarification
- From: Richard J Coppen <COPPEN@uk.ibm.com>
- To: Michael Combs <michaelcombs@gmail.com>
- Date: Thu, 10 Apr 2014 12:12:21 +0100
Hi Michael,
Many thanks for your comments and feedback
on CSD1.
The MQTT TC have now addressed these
under JIRA issue MQTT-192 > https://tools.oasis-open.org/issues/browse/MQTT-192
<
Best regards
Richard
From:
Michael Combs <michaelcombs@gmail.com>
To:
mqtt-comment@lists.oasis-open.org,
Date:
11/02/2014 23:38
Subject:
[mqtt-comment]
WILL publishing clarification
Sent by:
<mqtt-comment@lists.oasis-open.org>
There are several scenarios in which I am unsure if the
WILL should be published.
1) A client is connecting with the ID of an existing connected
client. It is my understanding that the currently connected client connection
should be closed and the new client should be connected. Should the will
of the closed/previous client be published?
2) A client loses connection, goes offline, etc., but
immediately reconnects.
A. The broker detects the loss of
connection (i.e. network socket closure).
B. The broker does not detect the
loss of connection (i.e. stateless radio communication and the client hardware
reboots within the keep alive timeout). In this scenario the reconnect
would take over the previous connection (placing this in category #1 above).
Should the WILL be published in either scenario?
Or, should the broker not publish the WILL provided the client reconnects
within a certain time period? WILL publishing seems unnecessary if
the client immediately reconnects. It also seems improper that the broker
could possibly have different behaviors (A, B) depending on whether it
can detect connection loss (thus making behavior dependent on communication
method: sockets, zigbee, etc).
3) A client sends a DISCONNECT message and immediately
terminates the socket connection. The broker, depending on the processing
model and message queue, could (and is very likely with async IO) recognize
the connection termination before processing the DISCONNECT message. The
broker now has to wait, set a timer, or look ahead in the mesage queue
to see if there is DISCONNECT for the client. A wait time, possibly the
broker keep alive timer, could resolve this issue as well as #2. This is
more of a technical/implementation issue, however, it relates to the protocol
in terms of ease and reliability of implementation
4) In the event that the broker must shut down. Should
WILL messages be published for connected clients? If so, how, since the
clients must all be disconnected before the shutdown? Do you publish the
WILLs before disconnecting any clients so they all receive each others
WILLS?
Thank you,
Michael Combs
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]