Stand with Ukraine flag

MQTT GUIDE

4 min read

MQTT Client ID and Client Take-Over

Quick answer

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.

Client A Broker Client B CONNECT id=sensor-1 CONNACK later — Client B connects with the same client ID CONNECT id=sensor-1 DISCONNECT reason: SESSION_TAKEN_OVER CONNACK Client B is now the live connection
Client take-over: a second connection with the same client ID displaces the first

Choosing a client ID

Use a stable, unique ID — one per device or app instance if you rely on persistent sessions — that is what lets a client resume its state across reconnects.
Avoid accidental sharing — two devices flashed with the same ID will keep kicking each other off in a reconnect loop. Derive IDs from something unique, like a serial number or MAC address.
Empty client ID — allowed (the broker assigns one), but it only suits throwaway, clean-session connections, since there is no stable key to map stored state back to.

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.