Topic Aggregation

Hi,

The short answer is "no".

First, if you look here -> https://community.rti.com/kb/types-matching

You will see that different topics (in rti dds that means different topic names) will not communicate.

How ever if you had one application trying to receive data on topic X and two applications trying to send data on topic X (assuming they have compatible qos):

It's possible to use mutable types so that the receiving application receives data from both sending applications. (with types similar to what you've described).

Note that:

a. you'll need to use ordinals that avoid collisions and setup the types correctly (https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/manuals/connext_dds/getting_started_extras/html_files/RTI_ConnextDDS_CoreLibraries_GettingStarted_ExtensibleTypesAddendum/index.htm#ExtensibleTypesAddendum/Type_Safety_and_System_Evolution.htm%3FTocPath%3DType%2520Safety%2520and%2520System%2520Evolution%7C_____0)

b. on the receiving application there won't be aggregation (or not exactly) - instead, each message sent by one of the application will be received by the receiving application.

Of course you can use an internal mapping to aggregate information (that also works in case you have a topic on which you don't always send the entire data but you always want the user to receive a full view of the latest values).

Hope this helps,

Roy.

Hey,

The concept of aggregating data is not, as far as I know, supported by the DDS standard.

data samples can be aggregated by the application using RTI DDS.

Regarding (I'm guessing) the option of using different topics with the typing:

Yes, you can set a route that will take data samples from topic 1 and move them to topic 2.

How ever, note that the router will basically be creating two data writers just like the ones your own application could be doing, so I'm not sure what the added value of using the routing service is in this scenario.

Unless of course you have something like:

1. topic 1 - sensor location

2. topic 2 - sensor status

and you want to aggregate this data into a topic like sensor info.

In this case I would look into the rate at which these two topics are being updated and other qos for each of them (maybe location is updated very infrequently but must be supplied to late joiners, maybe status is periodically updated but there's no need to even guarantee reliability).

If it makes sense to actually make them one topic, then do it. Optional fields are a bit more reasonable in that scenario.

If it doesn't make sense to make them one topic, consider using alternatives.

Roy.

Roy's answer is correct, in so far as you have greenfield development.

For legacy requirements, you can aggregate in an application or routing service. 

Some background:  The MultiTopic part of the DDS spec was designed for this use case.  Nobody supports it out of the box (last I looked)

In the past, I built a tool that would, given two idl and a configuration file, autogenerate java classes that implemented a sort of MultiTopic-like behavior.  It would do a table join of topics 1 and 2 and supply topic 3 to the application.  If either 1 or 2 received a sample, it would update the local 3 instance with the data from the 1 or 2 sample, and notify the application of a "topic 3 sample available".  It would also re-publish the joined sample on Topic 3 if required (this was the "bridge" mode that allowed for subscribers to Topic 1, 2 or 3 to not be disturbed or have to have the "MultiTopic-like" classes in them).

So the behavior is achievable, just not out of the box.

I never did it for C++ (was a PoC and I treat C++ as read-only source).