Here is my understanding of the unwritten behaviour:

A CONNECT packet must be the first packet a server receives from a client.

The client MUST not resend a CONNECT at any time.

If a server receives a CONNECT packet from an already connected client, this is a deviation from normal behaviour and the client MUST be disconnected.

Devil's advocate... Can a client CONNECT, DISCONNECT, CONNECT?

Other protocols (e.g. TLS) do allow this, but I'm not very keen, if at all, to permit this behaviour if it isn't specifically barred. It'd be pretty unusual and the only use case I see is to log in with different credentials without the overhead of re-establishing TCP and may be TLS. Given that any TLS layering has a strong likelihood of also being credential related, this would seem to be somewhat sub-optimal.

The 3.1 spec says this about DISCONNECT:
The DISCONNECT message is sent from the client to the server to indicate that it is about to close its TCP/IP connection.

That implies, without spelling it out explicitly, that a TCP connection cannot be reused.

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.

Currently this is no covered at all in the spec. Nothing prevents two connects being flowed. We should do something to clarify, narrowed down to three options below:

1. forbid second connect on same TCP Connection in all five cases
2. allow it only in the case where the client ID is the same (2 - 5). would have to specify what should happen if second connect were to fail
3. allow it in all five cases

TC Approve 03.10.2013