Connection Stealing (same client ID)

[Michael Combs]

 I apologize for the length, but I have some questions regarding clients connecting with the client ID of an existing client. This is what I refer to as connection stealing.  The spec simply indicates that the "older" client is disconnected before the new client connects. However, there are several different 'edge' scenarios in which this can happen and the treatment is not obvious, especially when you consider MQTT-SN and non TCP communication. 

1. A client loses connection.  The broker immediately receives a CONNECT request via the same communication channel (TCP, etc.) and protocol (MQTT) with the same ID. This is likely the same client but not necessarily so. If 'Clean Session' is false, I attempt to restore communication in the existing client object so that message queue (pending, unprocessed messages from the previous client), subscriptions, pending QoS 2, etc are uninterrupted. 

2. A client loses connection.  The broker receives a CONNECT request via the same communication channel and protocol with the same ID, but some time later (10 minutes as opposed to 5 seconds). This is still likely the same client but not necessarily so. If 'Clean Session' is false, I attempt to restore communication in the existing client object so that message queues, subscriptions are uninterrupted. I am using message expiration to limit the backlog of messages and to expire pending QoS 2 messages.

3.  The broker receives a CONNECT request via the same communication channel and protocol as an existing connected client with the same ID. This is clearly a different client, considering the previous client is still connected. If 'Clean Session' is false, do I disconnect the previous client and maintain the subscriptions, message queue, and pending QoS 2 messages? 

Consider the 3 scenarios above but with different communication channels and protocols:

4.  The broker receives a CONNECT request via a different communication channel (Bluetooth) and the same protocol as an existing client (connected or recently so) with the same ID. This is clearly a different client. If 'Clean Session' is false, do I disconnect the previous client and maintain the subscriptions, message queue, and pending QoS 2 messages? 

5.  The broker receives a CONNECT request via a some communication channel and different protocol (MQTT-SN) as an existing client (connected or recently so) with the same ID. If 'Clean Session' is false, do I disconnect the previous client and maintain the subscriptions, message queue, and pending QoS 2 messages? If so this would mean creating Topic IDs and sending REGISTER messages to the new MQTT-SN client?

To give you some context, I write public safety software ( 911 terminals, mobile software for law, fire, etc). Many of our clients are rural and scenario #1 and #2 happen frequently for our mobile units (in and out of network coverage). Bandwidth is very limited as well and so using CleanSession=FALSE prevents constantly resubscribing every time there is a connection loss. We will eventually be using embedded devices as with MQTT-SN, bluetooth, ZigBee, Radio, etc for system notifications. I can, to some extent, control the scenarios above by controlling the Client softwares use of ClientIDs. However, I would like to make sure my broker follows the spec as closely as possible. I can, to some extent, control the scenarios above by controlling the Client softwares use of ClientIDs. However, I would like to make sure my broker follows the spec as closely as possible.

Thanks,

-Michael

[Ian Craggs]

Hi Michael,

the short answer, is, if the clientid is the same and the protocol is MQTT, the spec says you must consider them to be the same client and take the action written in the spec.

Some observations. 

1) Currently, the MQTT-SN and MQTT specifications are independent.  There is nothing that says that MQTT-SN and MQTT clients with the same clientid have to be considered the same client.  In the implementation of RSMB which has both protocols, they are considered different.  MQTT-SN clients coming in over different transports *could* be considered different.  Future versions of the specifications might have something to say about this.

2) Even with the old limit of 23 characters, it is quite feasible to use unique enough client ids that the risk of accidental clashes is very unlikely.  The MQTT 3.1.1 specification removes this limit, so you can ensure very long client ids.

3) To ensure uniqueness, you also have the option of using SSL/TLS certificates, plus the userid/password fields.  You can use one or more of those in addition to the clientid to uniquely identify and authorize a client.

Ian