[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-419) Ambiguity over Session Expiry
[ https://issues.oasis-open.org/browse/MQTT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Banks updated MQTT-419:
------------------------------
Proposal:
Current text concerning Session Expiry in WD12.
-----------------------------------------------
3.1.2.11.2 Session Expiry Interval
17 (0x11) Byte, Identifier of the Session Expiry Interval.
Followed by the Four Byte Integer representing the Session Expiry Interval in seconds.
It is a protocol error to include the Session Expiry Interval more than once.
If the Session Expiry Interval is absent, the Session does not expire.
If it is set to 0, the Session ends when the Network Connection is closed.
The Client and Server MUST store the Session State after the Network Connection
is closed if the Session Expiry Interval is absent or greater than 0 [MQTT-xxxxx].
Non-Normative comment
The clock in the Client or Server may not be running for part of the time interval,
for instance because the Client or server are not running.
This might cause the deletion of the state to be delayed.
Refer to section 4.1 for more information about Sessions.
Refer to section 4.1.1 for details and limitations of stored state.
When the Session expires the Client and Server need not process the deletion of state atomically.
Non-Normative comment
Setting Clean Start to 1 and a Session Expiry Interval of 0,
is equivalent to setting CleanSession to 1 in the MQTT Specification Version 3.1.1.
Setting Clean Start to 0 and no Session Expiry Interval,
is equivalent to setting CleanSession to 0 in the MQTT Specification Version 3.1.1.
Non-Normative comment
A Client that only wants to process messages while connected will
set the Clean Start to 1 and set the Session Expiry Interval to 0.
It will not receive Application Messages published before it connected
and has to subscribe afresh to any topics that it is interested in each time it connects.
Non-Normative comment
A Client might be connecting to a Server using a network that provides
intermittent connectivity. This Client can use a short Session Expiry
Interval so that it can reconnect when the network is available again
and continue reliable message delivery. If the Client does not reconnect,
allowing the Session to expire, then Application Messages will be lost.
Non-Normative comment
When a Client connects with a long Session Expiry Interval,
or no Session Expiry at all, it is requesting that the Server
maintain its MQTT session state after it disconnects for an extended period.
Clients should only connect with a long Session Expiry Interval
if they intend to reconnect to the Server at some later point in time.
When a Client has determined that it has no further use for the
Session it should disconnect with a Session Expiry Interval set to 0.
Non-Normative comment
The Client can avoid implementing its own Session expiry and instead
rely on the Session Present flag returned from the Server to determine
if the Session had expired. If the Client does implement its own Session expiry,
it needs to store the time at which the Session State will be deleted
as part of its Session State.
Non-Normative comment
The Client and Server clocks might drift and not measure time
intervals accurately. The Client should always rely on the
Session Present flag in the CONNACK packet rather than try
to calculate whether the Server did keep its Session State.
........
4.1 Session State
In order to implement QoS 1 and QoS 2 protocol flows the Client and Server
need to associate state with the Client Identifier, this is referred to
as the Session State. The Server also stores the subscriptions as part
of the Session State.
The session can continue across a sequence of Network Connections.
It lasts as long as the Network Connection plus the Session Expiry Interval.
The Session state in the Client consists of:
QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.
QoS 2 messages which have been received from the Server, but have not been completely acknowledged.
The Session State in the Server consists of:
The existence of a Session, even if the rest of the Session State is empty.
The Client's subscriptions, including any Subscription Identifiers.
QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
QoS 1 and QoS 2 messages pending transmission to the Client.
QoS 2 messages which have been received from the Client, but have not been completely acknowledged.
Optionally, QoS 0 messages pending transmission to the Client.
If the Session is currently not connected, the time at which the Session State will be deleted.
Retained messages do not form part of the Session State in the Server,
they are not deleted as a result of a Session ending.
4.1.1 Storing Session State
The Client and Server MUST store Session State for the entire duration of the Session [MQTT-4.1.0-1].
A Session MUST last at least as long it has an active Network Connection [MQTT-4.1.0-2].
Non-Normative comment
The storage capabilities of Client and Server implementations will of course have limits in
terms of capacity and may be subject to administrative policies.
Stored Session State can be discarded as a result of an administrator action,
including an automated response to defined conditions.
This has the effect of terminating the Session.
These actions might be prompted by resource constraints or for other operational reasons.
It is possible that hardware or software failures may result in loss or corruption
of Session State stored by the Client or Server. It is prudent to evaluate
the storage capabilities of the Client and Server to ensure that they are sufficient.
4.1.2 Session State non-normative example
For example, an electricity meter reading solution might use QoS 1 messages to
protect the readings against loss over the network. However,
the solution developer might have determined that the power supply is sufficiently
reliable that the data in the Client and Server can be stored in
volatile memory without too much risk of its loss.
Conversely a parking meter payment application provider might decide that
there are no circumstances where a payment message can be lost so they
require that all data are force written to non-volatile memory
before it is transmitted across the network.
.........
>>>> Replace the two normative statements at the start of section 4.1.1 with:
The Client and Server MUST NOT discard the Session State while the network is connected [MQTT-4.1.0-1].
The Server MUST discard the Session State when
Network Connection has ended and the Session Expiry Interval has passed [MQTT-4.1.0-2].
was:
Current text concerning Session Expiry in WD12.
-----------------------------------------------
3.1.2.11.2 Session Expiry Interval
17 (0x11) Byte, Identifier of the Session Expiry Interval.
Followed by the Four Byte Integer representing the Session Expiry Interval in seconds.
It is a protocol error to include the Session Expiry Interval more than once.
If the Session Expiry Interval is absent, the Session does not expire.
If it is set to 0, the Session ends when the Network Connection is closed.
The Client and Server MUST store the Session State after the Network Connection
is closed if the Session Expiry Interval is absent or greater than 0 [MQTT-xxxxx].
Non-Normative comment
The clock in the Client or Server may not be running for part of the time interval,
for instance because the Client or server are not running.
This might cause the deletion of the state to be delayed.
Refer to section 4.1 for more information about Sessions.
Refer to section 4.1.1 for details and limitations of stored state.
When the Session expires the Client and Server need not process the deletion of state atomically.
Non-Normative comment
Setting Clean Start to 1 and a Session Expiry Interval of 0,
is equivalent to setting CleanSession to 1 in the MQTT Specification Version 3.1.1.
Setting Clean Start to 0 and no Session Expiry Interval,
is equivalent to setting CleanSession to 0 in the MQTT Specification Version 3.1.1.
Non-Normative comment
A Client that only wants to process messages while connected will
set the Clean Start to 1 and set the Session Expiry Interval to 0.
It will not receive Application Messages published before it connected
and has to subscribe afresh to any topics that it is interested in each time it connects.
Non-Normative comment
A Client might be connecting to a Server using a network that provides
intermittent connectivity. This Client can use a short Session Expiry
Interval so that it can reconnect when the network is available again
and continue reliable message delivery. If the Client does not reconnect,
allowing the Session to expire, then Application Messages will be lost.
Non-Normative comment
When a Client connects with a long Session Expiry Interval,
or no Session Expiry at all, it is requesting that the Server
maintain its MQTT session state after it disconnects for an extended period.
Clients should only connect with a long Session Expiry Interval
if they intend to reconnect to the Server at some later point in time.
When a Client has determined that it has no further use for the
Session it should disconnect with a Session Expiry Interval set to 0.
Non-Normative comment
The Client can avoid implementing its own Session expiry and instead
rely on the Session Present flag returned from the Server to determine
if the Session had expired. If the Client does implement its own Session expiry,
it needs to store the time at which the Session State will be deleted
as part of its Session State.
Non-Normative comment
The Client and Server clocks might drift and not measure time
intervals accurately. The Client should always rely on the
Session Present flag in the CONNACK packet rather than try
to calculate whether the Server did keep its Session State.
........
4.1 Session State
In order to implement QoS 1 and QoS 2 protocol flows the Client and Server
need to associate state with the Client Identifier, this is referred to
as the Session State. The Server also stores the subscriptions as part
of the Session State.
The session can continue across a sequence of Network Connections.
It lasts as long as the Network Connection plus the Session Expiry Interval.
The Session state in the Client consists of:
QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.
QoS 2 messages which have been received from the Server, but have not been completely acknowledged.
The Session State in the Server consists of:
The existence of a Session, even if the rest of the Session State is empty.
The Client's subscriptions, including any Subscription Identifiers.
QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
QoS 1 and QoS 2 messages pending transmission to the Client.
QoS 2 messages which have been received from the Client, but have not been completely acknowledged.
Optionally, QoS 0 messages pending transmission to the Client.
If the Session is currently not connected, the time at which the Session State will be deleted.
Retained messages do not form part of the Session State in the Server,
they are not deleted as a result of a Session ending.
4.1.1 Storing Session State
The Client and Server MUST store Session State for the entire duration of the Session [MQTT-4.1.0-1].
A Session MUST last at least as long it has an active Network Connection [MQTT-4.1.0-2].
Non-Normative comment
The storage capabilities of Client and Server implementations will of course have limits in
terms of capacity and may be subject to administrative policies.
Stored Session State can be discarded as a result of an administrator action,
including an automated response to defined conditions.
This has the effect of terminating the Session.
These actions might be prompted by resource constraints or for other operational reasons.
It is possible that hardware or software failures may result in loss or corruption
of Session State stored by the Client or Server. It is prudent to evaluate
the storage capabilities of the Client and Server to ensure that they are sufficient.
4.1.2 Session State non-normative example
For example, an electricity meter reading solution might use QoS 1 messages to
protect the readings against loss over the network. However,
the solution developer might have determined that the power supply is sufficiently
reliable that the data in the Client and Server can be stored in
volatile memory without too much risk of its loss.
Conversely a parking meter payment application provider might decide that
there are no circumstances where a payment message can be lost so they
require that all data are force written to non-volatile memory
before it is transmitted across the network.
.........
>>>> Replace the two normative statements at the start of section 4.1.1 with:
The Client and Server MUST NOT discard the Session State while the network is connected [MQTT-4.1.0-1].
The Client and Server MUST discard the Session State when
Network Connection has ended and the Session Expiry Interval has passed [MQTT-4.1.0-2].
> Ambiguity over Session Expiry
> -----------------------------
>
> Key: MQTT-419
> URL: https://issues.oasis-open.org/browse/MQTT-419
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: core
> Affects Versions: 5, wd12
> Reporter: Peter Niblett
> Assignee: Andrew Banks
> Priority: Minor
> Fix For: wd12
>
>
> WD11 and 12 are unclear about whether state can continue after the Session Expiry interval has elapsed or not. In particular whether server state gets deleted right away when a client with Session Expiry of 0 disconnects.
> You might imagine that it would get deleted when the Expiry interval elapses (so that if the client reconnects again at that point it would see no state, even if it had clean Start = 0). Text supporting this view can be found in 3.1.2.11.3 where it says
> "After reconnection, the Session lasts as long as the Network Connection plus the new Session Expiry Interval."
> and in 3.2.2.2 where it says "The Client can discard the Session state on both Client and Server by sending a DISCONNECT packet with Session Expiry set to 0.
> However the normative statement in 3.1.2.11.3 says
> "After the Network Connection is closed and the Session Expiry Interval has elapsed without a new connection being made, the Client and Server MUST delete the Session state they hold [MQTT-3.1.2-21]. "
> At first sight you might think that's saying the same thing, but I am told that the choice to use the word "After" rather then "When" is significant, and the intent is that the Server could keep the state for an indefinite length of time after the expiry and still be compliant. The reasons given for this are:
> i) the server might be down at the time the interval expires
> ii) it might crash while trying to do a Disconnect(SessionExpiry = 0)
> but we don't say that explicitly, so if you interpret "After" to mean "Any time after" then that particular compliance statement becomes untestable, and therefore rather pointless.
> We need to decide one way or the other (particularly in the case of 0)
> a) Do we tighten up by making the After into a When, or
> b) Make it clear that the State MUST last for at least as long as the Expiry interval, but could continue for some time after that. For clarity this would require changes to all the sentences I listed above.
> For what it's worth I favour a). I imagine that there are other normative statements that would not be true if the server crashes, and if we were to go through the spec watering them all down we might not have many left.
>
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]