Subscribing to topics with a wildcard

5 posts / 0 new
Last post
Offline
Joined: 02/17/2016
Posts: 19
Subscribing to topics with a wildcard

Hi.  I have a distributed network all running different instances of a piece of software.  Our current structure has a single IDL Type defined, however we break up different uses of that type via different topics.  Our topics are defined in a package style format with a number system  So for one type we could have several topics that look like so

appType.subsystem.control

1.1.1

1.1.2

1.1.3

All of those have the same appType and subsystem with control being the unique identifier of the topic.  But the IDL type is the same regardless of if its 1.1.2 or 3.2.4

I have a requirement to subscribe with wildcards, where the app could be configured to subscribe to 1.1.* and not know that 1,2, or 3 exist exclusively.  What is the best way to do this?  I see something about multi-topics in your documentation but that its not supported and there are not any examples.  I was thinking I could poll as well and get a listing of topics the DP has found with find_topic() but it says i cant look up topic data for remote topics which I believe is how I would figure out what the topic name is.  I am not keen on polling either, and i dont see a good listener to attach that lookup to like domain_livelyness or something.  Any suggestions?  

 

Organization:
Offline
Joined: 02/17/2016
Posts: 19

I should mention I am using RTI connext 5.1.0 currently as well.  

rip
rip's picture
Offline
Joined: 04/06/2012
Posts: 315

Partition QoS


Supports wildcards (Posix FNMATCH to be exact).  Single topic, multiple partitions on it.  And you can change it at runtime to change what you are looking at.

Offline
Joined: 02/17/2016
Posts: 19

I am familiar with the Partition QOS and was planning to use that to implement filters to solve another requirement I have for location filters.  Partition QoS would work great if I could change the rules so that it required more than 1 match to join.  

I feel like multitopics or some discovery mechnism would work to get the functionality I want.  I am confused as to why multitopics are unsupported now though, and what their history is.  Has this been migrated to Dynamic Data Types? RTPS publishes out the topics that are available to read as well so I should be able to intercept then and have a rule to decide if I want to make a datareader for that topic.

rip
rip's picture
Offline
Joined: 04/06/2012
Posts: 315

MultiTopic is hard. None of the vendors support it, which is a clue as to how hard.  At the same time, the use case footprint is small. I think that no vendor has ever supported it.

Dynamic Data is not multitopic. Dynamic Data allows you to build a publisher or subscriber for a topic, without using IDL or having pre-generated TypeSupport.

Extensible Types provides type evolution.  I have a type with X, Y coordinates, now I have a type with X, Y, Z.  I want an XYZ subscriber to also get data published by an XY publisher, and vice versa.  this is the Extensible Types framework, which is available in RTI Connect 5.2 (and to some extent in 5.1).

MultiTopic (worst case) requires support for heterogeneous types.  It is possible to create libraries (static code generation) that build a Multitopic that you can subscribe to.  (Builtin MultiTopic is probably not supported by any vendor, because DDS wants to do things at run-time.  The DDS "engine" would have to support the idea of assembling a Multitopic from available Topics under the hood, dynamically, at run-time.  DDS is already seen as "too heavyweight" in some fields).  I know that it is possible, I wrote one in either perl or java at some point.  There are always better ways to do it.

You absolutely can plug into the participant's discovery protocol, to find out what publishers and subscribers are being seen, and on which topics.  There's code in the documentation, look for DDS_PublicationBuiltinTopicDataand DDS_SubscriptionBuiltinTopicData in the documentation/code examples (can also use the search bar at the top of the page to find other's comments on those). 

What scale are you working at?  1s, 10s, 100s, 1000s of topics?

Keep in mind that the participants have to manage all these Topics a.s.c that you are creating.  That will eat up resources...