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] Updated: (MQTT-192) Will Message clarification (CSD review comment)

     [ http://tools.oasis-open.org/issues/browse/MQTT-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Coppen updated MQTT-192:

    Fix Version/s: 3.1.1
         Proposal: The Server SHOULD publish WILL Messages promptly. In the case of a Server shutdown or failure the server MAY defer publication of WILL Messages until a subsequent restart. If this happens there might be a delay between the time the server experienced failure and a Will message being published.   

> 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
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>             Fix For: 3.1.1
> 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]