Client ID in connection.created Event

[tsigcn]

I have enabled event exchange plugin and got some information in AMQP message header properties.
But I have not seen client id in properties, which is important for MQTT connections.
Would you please tell me how to get client id in event exchange plugin?
If there is no such property in the plugin ,is it possible to add it?
Thanks and regards.

[tsigcn]

I have seen client id in client properties of AMQP message header, but the property seems to be dropped when the event message converted to MQTT message.

Any advice will be appreciated.

[michaelklishin]

Here is where the connection.created keys are emitted:

• https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbitmq_mqtt/src/rabbit_mqtt_reader.erl#L146-L147
• https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbitmq_mqtt/include/rabbit_mqtt.hrl#L39-L59

So client_id is there in the event.

We won't guess as to how exactly you observe that the key is "lost". Please put together an executable way to reproduce, we do not guess in this community.

[tsigcn]

I have reproduce it and have following result:

This is the original message in RabbitMQ:

This is the message got via AMQP protocol:

This is the message got via MQTT protocol:

This is packets captured by WireShark :

And HEX dump:
db04260019757365725f77686f5f706572666f726d65645f616374696f6e00096d7174742d757365722600046e6f646500147261626269744068717261626269746d7130326c26000c636f6e6e65637465645f6174000d3137323535303836383532363726000b6368616e6e656c5f6d61780001302600096672616d655f6d617800013026000774696d656f75740002363026000e617574685f6d656368616e69736d00046e6f6e65260012706565725f636572745f76616c69646974790000260011706565725f636572745f7375626a6563740000260010706565725f636572745f69737375657200002600046e616d65002331302e312e392e3232363a37343636202d3e2031302e362e312e3139393a31363130322600047573657200096d7174742d7573657226000576686f737400012f26000873736c5f68617368000026000a73736c5f636970686572000026001073736c5f6b65795f65786368616e6765000026000c73736c5f70726f746f636f6c000026000373736c000566616c7365260009706565725f706f727400053431323231260009706565725f686f7374001a7b302c302c302c302c302c36353533352c323536362c3435367d260004706f727400053136313032260004686f7374001a7b302c302c302c302c302c36353533352c323536362c3237377d26000870726f746f636f6c000e7b274d515454272c7b352c307d7d260003706964002a3c7261626269744068717261626269746d7130326c2e313732353433333337342e3437333234302e303e26000f74696d657374616d705f696e5f6d73000d31373235353038363835323638

@michaelklishin
Thank you and hope for more suggestions.

[michaelklishin]

MQTT, even MQTTv5, does not have the concept of arbitrary user-provided headers so they are not translated.

[tsigcn]

As shown as above, the client id is perfect kept in original message and AMQP message, but cannot be seen in MQTT message and Wireshark packet.

Any advice will be appreciated.

[michaelklishin]

MQTT, even MQTTv5, does not have the concept of arbitrary user-provided headers so they are not translated.

Setting client_id directly during a translation is technically possible but the idea sounds very controversial to me.

So the only piece of advice I have is: consume the internal events using an AMQP 0-9-1 or AMQP 1.0 client.

[michaelklishin]

A few specific reasons why I do not like the idea of setting client_id from a header/application property:

1. This would be our own convention, likely not used by any other messaging tool
2. We do not know if will match user's intent
3. This will have a certain effect on throughput of workloads with AMQP 0-9-1 or AMQP 1.0 publishers and MQTT consumers, even though 99% of users would not expect client_id to be set for messages not originating from an MQTT publisher

@ansd might have something to add.

[tsigcn]

Using an AMQP 0-9-1 or AMQP 1.0 client maybe developer friendly, however, MQTT is expected by some IoT applications.
As you known, client id is important for IoT applications based on MQTT protocol.
Is it an option to set client id as a separated topic?
@michaelklishin
Thanks for your help.

[michaelklishin]

The internal event mechanism is exposed for monitoring systems. Monitoring systems do not have to use MQTT. RabbitMQ exposes these events to three protocols, including MQTT-specific connection fields that those protocols do not have.

Instead of telling us that "MQTT is expected" perhaps go tell the MQTT working group they should have introduced the concept of optional application-level metadata years ago, like AMQP 0-9-1 did in 2006, AMQP 1.0 around 2010, STOMP around 2009 and HTTP in the 1980-s.

RabbitMQ supports multiple protocols. Not all features will be available over every protocol for many reasons, including flaws and intentional limitations in protocol design. Take it or leave it.