OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [mqtt-comment] WILL publishing clarification

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


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]