[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=36421#action_36421 ] 

Andrew Schofield commented on MQTT-113:
---------------------------------------

I've modified the proposal to get the server to DISCARD ITS STATE in the event that the client has no memory of an existing session. Previously the client had to disconnect, reconnect CleanSession=true, disconnect and reconnect CleanSession=false to cause this. Since that's basically the only recovery action, it did seem a bit laborious.

> 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