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

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

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


Subject: [OASIS Issue Tracker] Created: (MQTT-192) Will Message clarification (CSD review comment)


Will Message clarification (CSD review comment)
-----------------------------------------------

                 Key: MQTT-192
                 URL: http://tools.oasis-open.org/issues/browse/MQTT-192
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Improvement
            Reporter: Richard Coppen


Comment raised by Michael Combs
Raising here for TC evaluation

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?

Initial response from Paul Freemantle

1) Yes the will topic should be published
2) Yes the will topic should be published
3) No, the topic should not be published
4) Not clear from the spec. A strict reading of the spec would give rise to a random set of clients receiving some Will messages and others not.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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