Point-to-Point with RTI DDS

8 posts / 0 new
Last post
Offline
Last seen: 3 years 6 months ago
Joined: 12/14/2015
Posts: 23
Point-to-Point with RTI DDS

I am writing simulation software, so I have no control over the system I am simulating.  It is a very multi-node network of systems that communicate with each other.  Lots of the nodes send/receive to/from multiple nodes, and RTI DDS is working great for that part of the simulation.

However, within the system are just a few nodes (say 3) that need to receive the same data so they are all registered for this data (topic).  But the catch is that they need to receive the data in order (hierarchical) and from a particular system.  For instance, node A needs to send the data (topic) to node B, then node B needs to send that same data (topic) to C.  My problem is that since B and C are registered for that same topic, they are getting it at the same time.  That would "break" the simulation.

Of course B can look at the source of the message and only accept it from A, and C can look at the source and only accept it from B.  This is a coded solution to the problem.

I am wondering if RTI DDS provides a way to send the SAME TOPIC in a hierarchical manner ( A to B, then B to C, then C to . . .) down a chain of nodes in the same domain?

 

 

 

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

Hey Herb,

I am not sure why you insist on sending the SAME TOPIC.

It would seem what you need is to send the same TYPE using different topics.

If you did that you could easily achieve the needed behavior.

Say your data type is SomeType and you are currently trying to use SomeTopic to send your data in some way.

Could you send SomeType on topic SomeTopicAtoB from a to b and then send it on SomeTopicBtoC from b to c?

Roy.

Offline
Last seen: 3 years 6 months ago
Joined: 12/14/2015
Posts: 23

Thanks for the reply.

Maybe it could work, but think of a military chain of command.

The general turns to the Colonel and says "Fire", the Colonel tells the Captain "Fire", the Captain tells the Lieutenant to "Fire", the Lieutenant tells the Sargeant to "Fire" and the Sargeant tells the operator to "Fire".

The simulation message (or topic) set is already created.  It just needs to be passed along from one to another in the correct order.  The reason this might be is that each echelon has certain responsibilities to perform before passing the message on.

Of course this can be solved in code.  All of the nodes register for the "Fire" topic, and every time it is sent from one node to another, all of the nodes receive it.  Then each node looks to see if the message is from its commander node before the message is processed or rejected.

Plus, every echelon is not always present, but each node in the network does know who its commander is for any particular scenario, and that is why topics like "Some TopicBtoC" may not work.  There would be a huge amount of Topics needed in order to cover all the possible permutations of the hierarchy.  For instance, "SomeTopicAtoB, ...AtoC, ...AtoD, AtoX, BtoC, BtoD, BtoE, ... an on it goes.

I guess maybe that RTI DDS does not support Point-to-Point directly (not sure).

 

 

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

Hey Herb,

There are ContentFilteredTopics which allow you to filter data that doesn't answer some criteria but in cases where you sometimes want data to pass from a to b and sometimes want it to pass from a to c (based on some other preconditions) you may want to solve that mechanism with code.

You could possibly alter the filter used by a reader during runtime so that you don't have to solve that with user made code though:

1. I'm not sure if you'll have to destroy the current reader and create a new one for the change to actually work

2. There are cases where content filtered topics won't spare you from "wasting" bandwidth and some processing on the readers side (I recall something about writer-side filtering not working with batching)

 

All the above said, the pattern which RTI DDS is most fitting for is anonymous pub sub and that means that getting point-to-point behaviour requires some work.

One solution which resembles udp is to add fields for source and destination.

The added value from RTI DDS is that you will still be able to create one-to-many, many-to-one and many-to-many communications (by reserving strings that represent groups and using those as source, destination, or both), make use of the various QoS solutions offered by rtps, and more.

 

I will stress again that saying "the simulation message (or topic)" is the wrong way to view topics.

Topics in dds (and indeed by some of the dictionary definitions) represent the subject that is discussed, and not the structure used to discuss it.

The message is of the type Fire (which may have things like: target, id of the person that issued the command, id of the person ordered to fire, and so on) but will you agree with me that it is highly unlikely for the general to order the simplest soldier to fire?

If you want to allow a hierarchy so that entities that are "higher up" can command all those below them you could use a simple int to receive that behaviour.

 

All in all there are many "solutions" but they depend on how much freedom you have in the code (can you modify the types, do the types already have the fields you need to obtain the behaviour you want, can you control the qos or the process of reader / writer creation, and so on).

If you give some more concrete information I think you'll get more concrete solutions.

 

Roy.

Offline
Last seen: 3 years 6 months ago
Joined: 12/14/2015
Posts: 23

Okay, it appears point-to-point is something RTI DDS does not support.

My message or data types have already been established before I started working on this project, and the general-to-private was just an example to illustrate my problem.

I do have a fairly simple solution using application code.  In the hierarchy, each receiver knows his superior, and he knows who sent each message.  So each receiver can just reject the messages not sent to the receiver by its superior by checking a source field in the message.

I tend not to want to use code for solutions (cuts down on maintenance) if I have a tool that will do it for me, but apparently this is not a paradigm supported by RTI DDS.

Thanks anyway.  You did help me zero in on the right solution.

 

Offline
Last seen: 8 months 1 week ago
Joined: 02/20/2014
Posts: 9

Just to be clear, since KickR didn't explicitly say it, but there shouldn't really be an application code solution to this, especially if you already added source fields to the message.  You should just be creating a ContentFilteredTopic of something along the lines of 'sourceName = "MySuperiorsName"', letting DDS do the work of actually ensuring the right messages get delivered to you.

Offline
Last seen: 3 years 6 months ago
Joined: 12/14/2015
Posts: 23

Thanks.  I will look into it. 

If it works, it will be a DDS RTI solution which I would prefer over a code solution.

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

Hey,

@jreisman: I did mention ContentFilteredTopics as the first and most obvious solution (as one can see in the post I made in 02/11/2016).

How ever, looking at what Herb said (I may want a reader to take orders from a specific writer at certain times and have the same reader take orders from another writer at another time) I mentioned that ContentFilteredTopics may not be 100% suitable as a complete solution.

(for example, Herb may need to replace the reader being used by an application when he wants to change the "hierarchy" around).

I also mentioned that from a performance pov (as compared with more standard p2p solutions), rti dds (even with content filtered topics) is likely to result in sub optimal performance, for example: if writers cannot filter on their side we will get some extra network load and extra work by the readers to filter out messages not directed at them, if writers can filter on their side they will do extra work to filter the data.

That being said, the benefits of rti dds (even in this context) are quite clear to me and I wouldn't recommend giving it up just because it requires some work (especially when standard p2p solutions require a lot of configuration and result in less flexible solutions).