MQTT GUIDE
4 min readMQTT Client ID and Client Take-Over
The MQTT client ID is a string that uniquely identifies a client to the broker and links it to its session state. Only one connection per client ID may be active at a time: if a second client connects with an ID already in use, the broker performs a take-over — disconnecting the existing connection and keeping the new one.
The client ID is the string an MQTT client puts in its CONNECT packet to identify itself to the broker. It is small but important: it is how the broker tells one client from another and how it links a reconnecting client back to its session state.
What the client ID is for
The broker uses the client ID as the key for a client’s session — its subscriptions and any queued messages. When a client reconnects with the same ID and asks to resume, the broker finds that state and restores it. The client ID is therefore the anchor of a client’s identity across reconnects, not just for a single connection.
Uniqueness and client take-over
Only one connection per client ID may be active at a time. If a second client connects with an ID that is already
connected, the broker performs a take-over: it keeps the new connection and disconnects the old
one. In MQTT 5.0, the displaced client is told why with the reason code Session taken over.
Choosing a client ID
Client IDs in TBMQ
TBMQ enforces one live connection per client ID across the whole cluster: a conflicting CONNECT takes
over the session and disconnects the previous connection with reason SESSION_TAKEN_OVER, even when the
two clients are connected to different nodes.
If a client sends an empty client ID, TBMQ generates one for it (and, for MQTT 5.0, returns it in the CONNACK as the Assigned Client Identifier) — but only for a clean session. A CONNECT that asks to resume a session (clean-start off) while sending no client ID is refused, because there would be no stable key to map the stored state back to. For TBMQ's client-ID behavior in full — cluster-wide uniqueness, generated IDs, and length limits — see the Client ID docs.
Frequently asked questions
Can two clients use the same client ID?
Not at the same time. The client ID must be unique among currently connected clients. If a second client connects with an ID already in use, the broker disconnects the first one — a behavior called client take-over.
What happens on a client ID collision?
The broker keeps the newest connection and closes the older one. In MQTT 5.0 the displaced client receives a DISCONNECT with reason code Session taken over (0x8E). This is defined by the protocol, so it is not a bug — usually it is a sign that two devices were accidentally given the same ID.
Can the client ID be empty?
Yes, in MQTT 3.1.1 and 5.0 a client may send an empty client ID and let the broker assign one. This only makes sense for a clean (non-persistent) session, because there is no stable ID to map stored state back to on reconnect.
Does the client ID have to be unique forever?
It must be unique among concurrent connections. Reusing the same ID later is normal and intended — that is exactly how a client reconnects to its persistent session and picks up queued messages.
Is the client ID the same as a username?
No. The client ID identifies the connection and its session; the username (with a password) is for authentication. A broker can authorize based on either, but they are separate fields in CONNECT.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.