[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-113) Handling of Session state mismatch between Client and Server
[ http://tools.oasis-open.org/issues/browse/MQTT-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Schofield updated MQTT-113:
----------------------------------
Proposal:
A new flag is added to the CONNECT control packet called StatePresent, carried in bit 0 of the Connect Flags byte. This indicates whether there is state present in the Client for the current Session.
In the CONNECT control packet, the combinations of the CleanSession and StatePresent flags have the following meanings.
If CleanSession is set to 1, StatePresent must be set to 0. The Client and Server MUST discard any previous Session and start a new one.
If CleanSession is set to 0 and StatePresent is set to 0, there is no stored state for the Session present in the Client. If the Server has no Session associated with the Client identifier, the Server creates a new Session. If the Server has a Session associated with the Client identifier, the Server MUST discard the previous Session, start a new one and accept the connection.
If CleanSession is set to 0 and StatePresent is set to 1, there is stored state for the Session present in the Client. If the Server has a Session associated with the Client identifier, the Server resumes communications with the Client based on state from the current Session. If there is no Session associated with the Client identifier, the Server MUST refuse the connected by sending a CONNACK packet containing a new return code 0x06 (Connection Refused, session state mismatch). The Client should discard its state and reconnect with StatePresent set to 0.
Here are the four scenarios with CleanSession=0.
1) Neither Client nor Server has stored state for this Session
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server cannot find the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
2) Client has no stored state for this Session, server DOES have stored state
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server finds the Session for this Client identifier
Server discards the Session
Server responds CONNECT(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
3) Client has stored state, server DOES NOT have stored state
Client sends CONNECT(CleanSession=0, StatePresent=1)
Server cannot find the Session for this Client identifier
Server responds CONNACK(Return code 0x06 - Session state mismatch)
Client discards its stored state
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server cannot find the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
4) Client and server both have stored state
Client sends CONNECT(CleanSession=0, StatePresent=1)
Server finds the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with the existing Session
was:
A new flag is added to the CONNECT control packet called StatePresent, carried in bit 0 of the Connect Flags byte. This indicates whether there is state present in the Client for the current Session.
In the CONNECT control packet, the combinations of the CleanSession and StatePresent flags have the following meanings.
If CleanSession is set to 1, StatePresent must be set to 0. The Client and Server MUST discard any previous Session and start a new one.
If CleanSession is set to 0 and StatePresent is set to 0, there is no stored state for the Session present in the Client. If the Server has no Session associated with the Client identifier, the Server creates a new Session. If the Server has a Session associated with the Client identifier, the Server MUST refuse the connection by sending a CONNACK packet containing a new return code 0x06 (Connection Refused, session state mismatch). The Client should reconnect with CleanSession set to 1 to request the Server to discard the Session.
If CleanSession is set to 0 and StatePresent is set to 1, there is stored state for the Session present in the Client. If the Server has a Session associated with the Client identifier, the Server resumes communications with the Client based on state from the current Session. If there is no Session associated with the Client identifier, the Server MUST refuse the connected by sending a CONNACK packet containing a new return code 0x06 (Connection Refused, session state mismatch). The Client should discard its state and reconnect with StatePresent set to 0.
Here are the four scenarios with CleanSession=0.
1) Neither Client nor Server has stored state for this Session
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server cannot find the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
2) Client has no stored state for this Session, server DOES have stored state
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server finds the Session for this Client identifier
Server responds CONNACK(Return code 0x06 - Session state mismatch)
Client sends CONNECT(CleanSession=1, StatePresent=0)
Server discards the Session
Server responds CONNACK(Return code 0x00 - Connection accepted)
Client sends DISCONNECT and closes the socket
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server cannot find the Session for this Client identifier - as expected
Server responds CONNECT(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
3) Client has stored state, server DOES NOT have stored state
Client sends CONNECT(CleanSession=0, StatePresent=1)
Server cannot find the Session for this Client identifier
Server responds CONNACK(Return code 0x06 - Session state mismatch)
Client discards its stored state
Client sends CONNECT(CleanSession=0, StatePresent=0)
Server cannot find the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with a new Session
4) Client and server both have stored state
Client sends CONNECT(CleanSession=0, StatePresent=1)
Server finds the Session for this Client identifier - as expected
Server responds CONNACK(Return code 0x00 - Connection accepted)
Messaging begins with the existing Session
> Handling of Session state mismatch between Client and Server
> ------------------------------------------------------------
>
> Key: MQTT-113
> URL: http://tools.oasis-open.org/issues/browse/MQTT-113
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.1.1
> Reporter: Andrew Schofield
> Fix For: 3.1.1
>
>
> One of the strengths of MQTT in mobile and M2M environments is the way the client and server can both persist state for CleanSession=0 sessions in order to resume message acknowledgement following reconnection.
> QoS 2 depends on both client and server being dependable in terms of remembering message IDs being acknowledged, and the server remembering the subscriptions. Assuming that client and server are implemented properly, that's generally OK. But what if either the client or server entirely forgets about its session leaving the other end with mismatched information? While that generally will not happen, there are situations in which it certainly could.
> For example, imagine a mobile phone app which uses MQTT and uses the app's isolated storage to maintain the MQTT session's persistent state. The app uses CleanSession=0 and the client ID is associated with the user of the app. If the app is uninstalled and reinstalled, or the user has to restore their phone, all of this state is lost from the client but the server may still remember the client. Alternatively, a hardware failure on the server might mean that a replacement server needs to be created without any of the original server's persistent state. Finally, if an MQTT client does not reconnect for an extended period, it might be reasonable to assume that it's permanently out of action or and to remove its session from the server. If the client is subsequently reconnected, the client's view of the session and the server's will not agree.
> This JIRA proposes some small changes to CONNECT and CONNACK control packets to detect these situations so that a client and server can get back into a known state.
--
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]