Topic Aggregation

6 posts / 0 new
Last post
Offline
Last seen: 3 years 1 week ago
Joined: 01/20/2015
Posts: 6
Topic Aggregation

Is it possible two aggregate two topics in one topic.

Suppose there is topic TOPIC_T1 with

STRUCT_T1

{

int x; //@key;

int y;

int z;

}

topic TOPIC_T2 with

STRUCT_T2

{

int x; //@key

int a;

int b;

}

topic TOPIC_T3

{

int x; //@key

int y;

int z;

int a;

int b;

}

datawriter1 is publishing TOPIC_T1 , datawriter2  is publishing TOPIC_T2 and datareader is subscribing TOPIC_T3.

Is it possible in connext whenever TOPIC_T1 and TOPIC_T2  is published, datareader get these values aggregated in TOPIC_T3 using mutable types or any other connext service.

 

Offline
Last seen: 2 months 6 days ago
Joined: 02/11/2016
Posts: 142

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.

Offline
Last seen: 3 years 1 week ago
Joined: 01/20/2015
Posts: 6

Thanks for the quick reply,

Is it also not possible using routing service?

Offline
Last seen: 2 months 6 days ago
Joined: 02/11/2016
Posts: 142

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.

rip
rip's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 04/06/2012
Posts: 315

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).

 

 

Offline
Last seen: 3 years 1 week ago
Joined: 01/20/2015
Posts: 6

Thankyou for your replies.