Search code examples
mqttactivemq-artemis

ActiveMQ Artemis MQTT 3.1 Client ID strict checking

According to the standard documents there is a difference between MQTT 3.1 and 3.1.1 in what's allowed as a client ID.

The 3.1 specification is more strict, it demands any broker must refuse connections if the client ID is above 23 chars:

If the Client ID contains more than 23 characters, the server responds to the CONNECT message with a CONNACK return code 2: Identifier Rejected.

The 3.1.1 specification defines a charset, but allows that the broker may deviate from the strict requirements:

The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5].

The Server MAY allow ClientId’s that contain more than 23 encoded bytes. The Server MAY allow ClientId’s that contain characters not included in the list given above.

I am using Apache ActiveMQ Artemis with the standard MQTT acceptor provided with the official container image broker.xml config.

Unfortunately, I must exchange messages with a client that only supports 3.1 but exceeds the limit for the length and allowed chars in the client ID. If ActiveMQ Artemis is forced to use 3.1, it applies the strict checking and denies the connection.

MqttIdentifierRejectedException: invalid clientIdentifier

Is there a setting that allows to configure ActiveMQ Artemis to be more lenient about the Client ID?

I could not find anything in the documentation. Unfortunately I cannot change the client behaviour.

Solution

  • ActiveMQ Artemis does allow client IDs longer than 23 characters for MQTT 3.1.1 and 5 clients since that is allowed according to those specifications.

    However, as you note, the MQTT 3.1 specification doesn't allow client IDs longer than 23 characters.

    ActiveMQ Artemis uses Netty's MQTT codec implementation and it fails to decode a CONNECT packet from a 3.1 client with a client ID longer than 23 characters. There's really nothing the broker can do about it aside from using a different codec or changing Netty's. That said, most codecs are likely to enforce the specification just like Netty does and Netty likely would reject any such change.

    In short, specifications exist for a reason. Clients should follow them and should not be surprised when a server enforces them.