There are several improvements you can get in that scenario with keys:
1.- You avoid the proliferation of topics, improving the scalability: the discovery process takes fewer messages, and the memory used to store the remote endpoints is lower.
2.- You apply the QoS per key. Imagine you have several vehicles/robots, and you are sending the position. You also want to implement durability with keep_last=1 and transient local, so you send the latest published position to the late joiners. Currently, you would need to create a position topic per robot. You could think of creating a topic like this:
Identifier robot
long x
long y
But this won’t work, as keep_last=1 would store the latest published position, but just one of an arbitrary robot. But in DDS, if you use keys, and define your topic like this:
@key Identifier robot
long x
long y
Then, a transient local durability with keep_last=1, is storing the latest published position per @key Identifier , so the middleware is working for you.
Other QoS work the same way, so you can do the same as you do with multiple topics, just implementing keys, and on top of that, grouping topics with the same meaning in a single topic, simplifying a lot your application.
There are other many advantages, for example, you could create a content filter topic to get the positions of a subset of robots, just with a filter expression.
So, in a nutshell, you get:
- Improved scalability and performance
- Simpler and more elegant Information model
- New powerful features.
And as @superware mentions, this is already available in any DDS implementation.
We are thinking of offering some support for this, at least for Fast DDS RMW.