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-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: 
Tighten up the session state description in the section on Clean Session. 

3.1.2.4 Clean Session 
Position: bit 1 of the Connect Flags byte. 

This bit specifies the handling of the Session state. 

The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state. 

If set to 0, the Server resumes communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server creates a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected. After disconnection, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state. It MAY also store QoS 0 messages that meet the same criteria.

If set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this session MUST NOT be reused in any subsequent Session.

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. 
• 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.

Retained publications do not form part of the Session state in the Server. They MUST NOT be deleted when the Session ends. 




CONNACK Control Packet change
Add a flag to enable the server to tell the client whether it has stored session state.

3.2.2 Variable header
The variable header format is shown in the table below.

Byte 1 is the "Connect Acknowledge Flags". Bits 7-1 are reserved and must be set to 0.

Bit 0 is the Session Present Flag.

3.2.2.1 Session Present
Position: bit 0 of the Connect Acknowledge Flags.

If the Server accepts a connection with CleanSession set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a zero return code in the CONNACK packet.

If the Server accepts a connection with CleanSession set to 0, the value set in Session Present depends on whether the Server already has stored Session state for the supplied client ID. If the Server has stored Session state, it MUST set Session 
Present to 1 in the CONNACK packet. If the Server does not have stored Session state, it MUST set Session Present to 0 in the CONNACK packet. This is in addition to setting a zero return code in the CONNACK packet.

The Session Present flag enables a Client to establish whether the Client and Server have a consistent view about whether there is already stored Session state. 

Once the initial setup of a Session is complete, a Client with stored Session state will expect the Server to maintain its stored Session state. In the event that the value of Session Present received by the Client from the Server is not as expected, the Client can choose whether to proceed with the Session or to disconnect. The Client can discard the Session state on both Client and Server by disconnecting, connecting with Clean Session set to 1 and then disconnecting again.

If a server sends a CONNACK packet containing a non-zero return code it MUST set Session Present to 0.

  was:
Tighten up the session state description in the section on Clean Session.

3.1.2.4 Clean Session
Position: bit 1 of the Connect Flags byte.

This bit specifies the handling of the Session state.

The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state.

The Session state in the Client consists of:
•	The existence of a Session, even if the rest of the Session state is empty.
•	QoS 1 and QoS 2 messages for which transmission to the Server is incomplete or where transmission to the Server has not yet been started.
•	QoS 2 messages for which transmission from the Server is incomplete.
•	The Client MAY store QoS 0 messages for later transmission to the Server.

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, potentially including subscriptions made by an administrator.
•	All QoS 1 and QoS 2 messages for which transmission to the Client is incomplete or where transmission to the Client has not yet been started.
•	QoS 2 messages for which transmission from the Client is incomplete.
•	The Server MAY store QoS 0 messages for later transmission to the Client.

Retained publications do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends.

The Client and Server MUST store the Session after the Client and Server are disconnected. After disconnection, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state. It MAY also store QoS 0 messages that meet the same criteria.


CONNACK Control Packet change
Add a flag to enable the server to tell the client whether it has stored session state.

3.2.2 Variable header
The variable header format is shown in the table below.

Byte 1 is the "Connect Acknowledge Flags". Bits 7-1 are reserved and must be set to 0. Bit 0 is the Session Present Flag.

3.2.2.1 Session Present
Position: bit 0 of the Connect Acknowledge Flags.

If the Server accepts a connection with CleanSession set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a zero return code in the CONNACK packet.

If the Server accepts a connection with CleanSession set to 0, the value sets in Session Present depends on whether the Server already has stored Session state for the supplied client ID. If the Server has stored Session state, it MUST set Session Present to 1 in the CONNACK packet. If the Server does not have stored Session state, it MUST set Session Present to 0 in the CONNACK packet. This is in addition to setting a zero return code in the CONNACK packet.

The Session Present flag enables a Client to establish whether the Client and Server have a consistent view about whether there is already stored Session state. Once the initial setup of a Session is complete, a Client with stored Session state will expect the Server to maintain its stored Session state. In the event that the value of Session Present received by the Client from the Server is not as expected, the Client can choose whether to proceed with the Session or to disconnect. The Client can discard the Session state on both Client and Server by disconnecting, connecting with Clean Session set to 1 and then disconnecting again.

If a server sends a CONNACK packet containing a non-zero return code it MUST set Session Present to 0.


> 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 the CONNACK control packet 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]