MQTT5 transport spec does not support uE instance IDs

[sophokles73]

With the current topic structure for uE-to-uE communication, it is not possible to filter on uEntity instance IDs.

Example:

uEntity 0x5678 version 0x02 on device1 wants to add a listener for requests to its resource 0xA100 originating from any instance of uEntity with type ID 0x1234 on any other device (connected to the same MQTT broker). This would result in topic filter

+/FFFF1234/+/0/device1/5678/2/A100

However, if the uEntity with uE ID 0x00041234 on device2 sends a corresponding request, it would get published on topic

device2/41234/2/0/device1/5678/2/A100

which would not match the topic filter used to register the listener on device1 (because 41234 is not the same as FFFF1234).

[sophokles73]

One option would be to put the uEntity type and instance IDs into separate topic segments, e.g. using a topic filter like

{source.authority_name}/{source.ue_type_id}/{source.ue_instance_id}/{source.ue_version_major}/{source.resource_id}/{sink.authority_name}/{sink.ue_type_id}/{sink.ue_instance_id}/{sink.ue_version_major}/{sink.resource_id}

For the example above, this would result in topic filter

+/1234/+/+/0/device1/5678/0/2/A100

and the request would get published to topic

device2/1234/4/2/0/device1/5678/0/2/A100

which would match the topic filter.

[sophokles73]

@PLeVasseur @jjj-vtm @ValMobBIllich WDYT?

[PLeVasseur]

Yup, this proposal makes sense to me! Maybe just because I've had to look at the u32 representation with the instance id in the top 16 bits and the type in the bottom 16 bits that it was briefly harder to read what was going on, but I think this is fine.

[sophokles73]

Well, I thought we would order the segments from the abstract towards the specific ... ;-)

[jjj-vtm]

For me it also makes sense and I guess zenoh has the same problem. The only problems I see is that a) it is a breaking change and b) we increase the topic tree depth which causes higher load on the MQTT broker.

[sophokles73]

a) it is a breaking change

True, but I guess we do not have much of an installation base (yet) and we are still in alpha release phase anyway, so breaking the API should still be acceptable.

and b) we increase the topic tree depth which causes higher load on the MQTT broker.

However, this only affects uE-to-uE traffic within a single vehicle where we only expect a limited number of topics anyway, right?

[jjj-vtm]

True, but I guess we do not have much of an installation base (yet) and we are still in alpha release phase anyway, so breaking the API should still be acceptable.

Correct, I am fine with it.

However, this only affects uE-to-uE traffic within a single vehicle where we only expect a limited number of topics anyway, right?

It would affect all uProtocol MQTT communication since we would use 10 level deep topics instead of 8 but I think the impact should be negligible at least for small/medium deployments.

[sophokles73]

closed via #254