The CONNECT packet

The MQTT CONNECT Control packet always contains a payload. It is the first packet, which the client must send to the server after the connection is established.

It can only be sent once by the client, if a second CONNECT packet is sent, the server (broker) must process it as a protocol violation and disconnect the client.

The payload may contain several different fields:

• unique Client identifier (clientid) – always present
• will topic
• will message
• user name
• password (requires user name to be present as well!)

The clientid is required, the other fields are optional. The presence of the optional fields is determined by flags in the header.

Screenshot: OASIS Open MQTT v3.1.1 spec

Limits

Here are the limits which should be supported by compliant brokers:

• clientid: 23 UTF-8 encoded bytes
• user name max. 655535 bytes after encoding (UTF-8 encoded)
• password: 0 to 65535 bytes of binary data
• message limit size: 268435455 bytes

The following characters for the client id are required to be supported by any broker meeting the MQTT v3.1.1 spec:

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

Other characters and longer client ids can be supported optionally by the broker.

23 characters is plenty. Remember, these are not bits, but characters. If you use base58 encoding, for example, you get 58^23 combinations ~ 3,62E+40 ~ 36211277946678500000000000000000000000000 combinations. If you don’t – then even more.

Optionally clientid’s with zero bytes length can be supported by the broker. In this case, the broker must assign a unique clientid to the client. Not all brokers support this (“MAY” as per specification).

The user name must be a UTF-8 encoded string. The password can be binary data.

The message can also be binary data.

Increasing Limits

In order to increase the clientid limit in VerneMQ, you can set an option, max_client_id_size:

https://docs.vernemq.com/configuration/nonstandard

it defaults to 23.

Client ID should be unique

In MQTT normally clients should have distinct clientids, even if they have different usernames.

If two clients share the client id, they will be end up in a ping-pong of connect-disconnect attempts, as the broker does not usually allow connections for two clients with the same clientid.

(I believe VerneMQ has this option, but I also believe it to be deprecated; in any case it’s better not to design with it in mind, to stay compatible with other brokers!).

Ref

• http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf
• see section 1.5.3 for limits on generic UTF-8 encoded strings, which apply to the username