[OASIS Issue Tracker] Commented: (MQTT-55) What should happen if a client issues multiple connect calls on the same TCP Connection

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

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

Peter Niblett commented on MQTT-55:
-----------------------------------

I suspect that today's clients don't actually let anyone send a second CONNECT packet, but the specification should defined what happens if they were to.  Before one rushes to dismiss this out of hand, it's worth considering a few different cases:

1. A second CONNECT which has a different client Identifier.   

2. A second CONNECT with the same client Identifier but different values of the Will parameters (Will Flag, Will Topic, Will Message, Will Retain, Will QoS)

3. A second CONNECT with the same client Identifier but different values of User Name and/or Password

4. A second CONNECT with the same client Identifier but a different value of the cleanSession flag

5. A second CONNECT identical in all respects to the first one.

The first of these would be a legitimate thing to do if we were to support the multiplexing of two different MQTT connections over a single TCP/IP connection. However we (deliberately) don't have enough fields in the MQTT control packet headers to support this kind of thing and we have an (again unwritten) assumption that there can be at most one MQTT connection on any TCP/IP connection.  So I agree that this case should be treated as an error and cause a disconnection.

There's something that makes me a bit uneasy about treating the remaining cases as errors, and that's the fact that if this CONNECT packet had come in on a completely different TCP/IP connection (possibly from another client) then it would likely be accepted. It would have thrown off the existing client, but it would have worked itself, so why prevent its use if it is sent on the same connection?. However that's a rather theoretical point - is there any value to the user in any of these use cases?

I would argue that there is some utility in 2 and 3 for a client that is using cleanSession = 1, as it lets them change properties of the connection without the risk of losing messages by having to do a disconnect and reconnect. In particular if the password were some kind of time-limited credential it gives the ciient the opportunity to present the new credential without having to disconnect first.  

There's a marginal benefit in allowing 4, for cases where a client really wants to run with cleanSession = 0, but wants to do a one-time clean up the first time it connects in case there's been debris left around from some previous existence. To do this it has to send two successive CONNECT packets (the first with cleanSession  = 0, the second with cleanSession = 1) and it would be friendly to such clients to let them do this without forcing them to bring the TCP/IP connection down and up again.



> What should happen if a client issues multiple connect calls on the same TCP Connection
> ---------------------------------------------------------------------------------------
>
>                 Key: MQTT-55
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-55
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>             Fix For: 3.1.1
>
>
> The current specification does not address this situation

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