How can a writer tell if the right listener is there? How to set EntityName in C++?

2 posts / 0 new
Log in or register to post comments
Last post
Wed, 12/12/2018 - 09:18
#1
aaronb
Offline
Last seen: 3 years 9 months ago
Joined: 03/12/2018
Posts: 32
How can a writer tell if the right listener is there? How to set EntityName in C++?

I have a datawriter that wants to send something to a specific reader.  I need to wait until discovery is complete before I send it.  How can I verify that the specific reader has been discovered before I send it?

Keep in mind that the topic might be subscribed to by other things, like traffic recorders and analyzers (or it might not).  Those listeners must be ignored.

It is my impression that DDS_PublicationMatchedStatus is not sufficient  - because this will only tell me that subscribers exist, not whether the correct one is there.  Instead, I think I need to use EntityName

I would very much prefer to do this in my C++ class's constructor initializer list, as I have all of my particpants, publishers, subscribers, etc, being initialized there.

However, the example I can find on RTI's website puts an EntityName into a QoS, and then uses that to initialize the publisher.

// Creating a publisher with modified QoS
dds::pub::qos::PublisherQos qos;
qos << rti::core::policy::EntityName("PublisherName");
dds::pub::Publisher publisher2(participant, qos);
 
1) Can I do this to a DataWriter/DataReader instead of a QoS?
2) Can it be done in an initializer list somehow, rather than with an operator?  I'd like to keep it in the initializer list of the class constructor, rather than having to move all of the class construction out into the body of the constructor.
 
 
 
Top
Thu, 12/13/2018 - 11:59
KickR
Offline
Last seen: 3 months 5 days ago
Joined: 02/11/2016
Posts: 144

Hey,

This is not considered good practice, as RTI is (best used as) an anonymous pub/sub solution.

If you need to provide future readers with historical data there are a few alternatives to achieving that (most notably durability service, but I believe topic queries could also work even if durability is set to volatile).

As you've mentioned, you can "easily" use participant names to detect "specific" participants (although this is not "safe", a malicious participant can pretend to be the "specific" participant).

If you want to detect specific data writers / readers I believe you can use user meta data (but I remember something about this not working well inside DDS_PublicationMatchedStatus  unless you're using 5.3.0?).

 

But again, think again if you really must use this approach.

 

Good luck either way,

Roy.

Top