[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 ]
Peter Niblett updated MQTT-192:
-------------------------------
Proposal:
These comments have pointed out that there are several places where we should tidy up and tighten the wording related to the Will Message. There are currently several normative statements to be found both in sections 3.1.2.5 and 3.14.4 and an additional statement (which doesn't contain the word MUST and so isn't labelled as normative) in 3.1.3.3.
1. The first normative statement is [MQTT-3.1.2.8] which can be found in section 3.1.2.5. This currently says
"If the Will Flag is set to 1 this indicates that a Will Message MUST be published by the Server when the Server detects that the Client is disconnected for any reason other than the Client flowing a DISCONNECT Packet".
While the meaning of this seems reasonably clear, there are some issues with it:
i) It's clear that no Will Message is sent if it is the server that performs the disconnection when it receives the DISCONNECT, but in 3.14.4 we state that "After sending a DISCONNECT Packet the Client MUST close the Network Connection". Now we don't want a Will Message when this happens either, but in this case it's not really the flowing of the DISCONNECT that causes the loss of the connection, but rather it is a decision of the client application that causes both the DISCONNECT to be flowed and the network connection to be closed. A small point maybe, but it manifests itself at the server in Michael's question 3, where he asks what happens if the server detects the dropped connection before it sees the DISCONNECT packet.
ii) It's not entirely clear what should happen in a race condition where a server is in the process of shutting down (and thus disconnecting the clients itself) when one of them sends a DISCONNECT
iii) It's a bit redundant to talk here about situations when the Will Message isn't published because we subsequently talk (in two places) about how the Will Message gets discarded when a DISCONNECT is processed. So it can't be published if it has been discarded.
To address these we propose to change statement 3.1.2-8 to emphasise the positive bit (the bit about storing the Will Message and publishing it) while still acknowledging that it might have been discarded by the time the network connection actually ends.
Change Statement 3.1.2-8 as follows:
>>If the Will Flag is set to 1 this indicates that a Will Message MUST be stored and subsequently published when the network connection is closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8]. Situations in which the Will Message is published include, but are not limited to:<<
---------------------------------------------------
2. The next change is a minor editorial change to [MQTT-3.1.2.10]. This currently says
"The will message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. If the Will Flag is set to 0, no will message is published[MQTT-3.1.2.10]
The second sentence (about what happens if the Will Flag is 0) is a separate thought and should not be part of the [MQTT-3.1.2.10] statement. It's really a statement of the obvious rather than a normative statement because if there is no Will Message then it clearly can't be published.
So we propose to modify 3.1.2-10 to move that second sentence out of it:
>>The Will Message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. [MQTT-3.1.2-10] If the Will Flag is set to 0, no will message is published.<<
----------------------------------------------------
3. Question 4 from Michael asks what happens if the server shuts down. While this is largely covered by [MQTT-3.1.2-8] there is the question of what happens if it has to shut down before it is able to start publishing the Will Messages.
We propose to add the following normative statement to cover this case as the last line before Section 3.1.2.6:
>> 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. <<
-----------------------------------------------------
4. Section 3.1.3.3 contains a restatement of the old [MQTT-3.1.2-8] text:
"The Will Message defines the Application Message that is to be published to the Will Topic if the Client is disconnected for any reason other than the Client sending a DISCONNECT Packet."
To keep this consistent with the new text in 3.1.2.5 we propose to replace it with a reference to that section as follows:
>>The Will Message defines the Application Message that is to be published to the Will Topic as described in 3.1.2.5<<
------------------------------------------------------
5. Section 3.14.4 (Disconnect response) currently contains another normative statement referring to the Will Message
"On receipt of DISCONNECT the Server MUST discard the Will Message without publishing it [MQTT-3.14.4-3], see Section 3.1.2.5. "
This duplicates part of [MQTT-3.1.2.10] (see above) and it's not good style to have two normative statements saying the same thing. On the other hand it is useful to be able to refer to the discarding of the Will Message at this point.
So we propose to remove the highlighting and the normative statement tag [MQTT-3.14.4-3] and reword it slightly to refer back to the place where the real normative statement can be found:
line 1381: Remove "MUST" change "discard" to "Discards" remove conformance statement label [MQTT-3.14.4-3] thus removing highligher marks.... Replace "see Section 3.1.2.5" with "as described in Section 3.1.2.5"
------------------------------------------------------
6. Minor editorial... Section 3.1.2.7 "Will Retain" would benefit from an introductory sentence
Under 3.1.2.7 "Will Retain" add >> This bit specifies if the Will Message is to be Retained when it is published<<
was:
These comments have pointed out that there are several places where we should tidy up and tighten the wording related to the Will Message. There are currently several normative statements to be found both in sections 3.1.2.5 and 3.14.4 and an additional statement (which doesn't contain the word MUST and so isn't labelled as normative) in 3.1.3.3.
1. The first normative statement is [MQTT-3.1.2.8] which can be found in section 3.1.2.5. This currently says
"If the Will Flag is set to 1 this indicates that a Will Message MUST be published by the Server when the Server detects that the Client is disconnected for any reason other than the Client flowing a DISCONNECT Packet".
While the meaning of this seems reasonably clear, there are some issues with it:
i) It's clear that no Will Message is sent if it is the server that performs the disconnection when it receives the DISCONNECT, but in 3.14.4 we state that "After sending a DISCONNECT Packet the Client MUST close the Network Connection". Now we don't want a Will Message when this happens either, but in this case it's not really the flowing of the DISCONNECT that causes the loss of the connection, but rather it is a decision of the client application that causes both the DISCONNECT to be flowed and the network connection to be closed. A small point maybe, but it manifests itself at the server in Michael's question 3, where he asks what happens if the server detects the dropped connection before it sees the DISCONNECT packet.
ii) It's not entirely clear what should happen in a race condition where a server is in the process of shutting down (and thus disconnecting the clients itself) when one of them sends a DISCONNECT
iii) It's a bit redundant to talk here about situations when the Will Message isn't published because we subsequently talk (in two places) about how the Will Message gets discarded when a DISCONNECT is processed. So it can't be published if it has been discarded.
To address these we propose to change statement 3.1.2-8 to emphasise the positive bit (the bit about storing the Will Message and publishing it) while still acknowledging that it might have been discarded by the time the network connection actually ends.
Change Statement 3.1.2-8 as follows:
>>If the Will Flag is set to 1 this indicates that a Will Message MUST be stored and subsequently published when the network connection is closed unless it has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8]. Situations in which the Will Message is published include, but are not limited to:<<
---------------------------------------------------
2. The next change is a minor editorial change to [MQTT-3.1.2.10]. This currently says
"The will message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. If the Will Flag is set to 0, no will message is published[MQTT-3.1.2.10]
The second sentence (about what happens if the Will Flag is 0) is a separate thought and should not be part of the [MQTT-3.1.2.10] statement. It's really a statement of the obvious rather than a normative statement because if there is no Will Message then it clearly can't be published.
So we propose to modify 3.1.2-10 to move that second sentence out of it:
>>The will message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. [MQTT-3.1.2-10] If the Will Flag is set to 0, no will message is published.<<
----------------------------------------------------
3. Question 4 from Michael asks what happens if the server shuts down. While this is largely covered by [MQTT-3.1.2-8] there is the question of what happens if it has to shut down before it is able to start publishing the Will Messages.
We propose to add the following normative statement to cover this case as the last line before Section 3.1.2.6:
>> 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. <<
-----------------------------------------------------
4. Section 3.1.3.3 contains a restatement of the old [MQTT-3.1.2-8] text:
"The Will Message defines the Application Message that is to be published to the Will Topic if the Client is disconnected for any reason other than the Client sending a DISCONNECT Packet."
To keep this consistent with the new text in 3.1.2.5 we propose to replace it with a reference to that section as follows:
>>The Will Message defines the Application Message that is to be published to the Will Topic as described in 3.1.2.5<<
------------------------------------------------------
5. Section 3.14.4 (Disconnect response) currently contains another normative statement referring to the Will Message
"On receipt of DISCONNECT the Server MUST discard the Will Message without publishing it [MQTT-3.14.4-3], see Section 3.1.2.5. "
This duplicates part of [MQTT-3.1.2.10] (see above) and it's not good style to have two normative statements saying the same thing. On the other hand it is useful to be able to refer to the discarding of the Will Message at this point.
So we propose to remove the highlighting and the normative statement tag [MQTT-3.14.4-3] and reword it slightly to refer back to the place where the real normative statement can be found:
line 1381: Remove "MUST" change "discard" to "Discards" remove conformance statement label [MQTT-3.14.4-3] thus removing highligher marks.... Replace "see Section 3.1.2.5" with "as described in Section 3.1.2.5"
------------------------------------------------------
6. Minor editorial... Section 3.1.2.7 "Will Retain" would benefit from an introductory sentence
Under 3.1.2.7 "Will Retain" add >> This bit specifies if the Will Message is to be Retained when it is 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]