[OASIS Issue Tracker] Commented: (MQTT-113) Handling of Session state mismatch between Client and Server

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/MQTT-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36339#action_36339 ] 

Andrew Banks commented on MQTT-113:
-----------------------------------

        The proposal detects the presence or absence of stored state but does not detect 
        whether the client or server has the correct matching version of the state. 
        This situation can occur occurs where a fail over of the server happens or where
        the client or server state is restored from a backup.  

        Here is a modified proposal that uses version numbers rather than a flag to detect
        whether the state in the server is at the matching level. This assumes that state is
        not lost or backed up  while the network connection exists between the client and server. 

        Client                                                                                             Server


         Initial condition, no state in either the client or server.


                                     Connect, CleanSession=0, State=V0  ---------------->

                                                                                                               Persist V1
                                                  <---------------- Connack, OK, or RC 0x06 if state exists and did not contain V1.

         Persist V0+1 = V1

                     
         Later after a disconnect or network failure.

         Connect, CleanSession=0, State=V1  ---------------->
                                                                                                                Persist V2
                                                  <---------------- Connack, OK,   or RC 0x06 if state did not contain V1 or V2.
         
         Persist V1+1 = V2



         Later after a disconnect or network failure.

         Connect, CleanSession=0, State=V2  ---------------->
                                                                                                                Persist V3
                                                  <---------------- Connack, OK,  or RC 0x06 if state did not contain V2 or V3.
         Persist V2+1 = V3


The server must accept the VN or VN-1 state in case the CONNACK did not arrive at the client
and the client did not successfully persist VN.
I suggest that V should be two bytes and allowed to wrap, implying that the client 
or server would have to revert to saved state 2**16 (or 2**16-1) connection attempts 
previously to fail to detect the mismatch. 

CSD02 line 915 permits the client to send messages before it receives the CONNACK. If
the client chooses to do this, it runs the additional risk of accepting messages based
on mismatched server state.

> 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