Hello,
i want to implement a monitoring application for our system, capable of inspecting published data and publishing user data on arbitrary topic. Topic types can vary so I'm using DynamicDataReaders and DynamicDataWriters. It's not a problem to publish or subscribe data with known TypeCode (to create DDSDynamicDataTypeSupport object). I'm currently using following approach: For every generated type I automatically generate small application which print selrialized TypeCode in text file in specific location. Later this text file can be used to create TypeCode object for specific type name. So far everything works but I'd like to be able to dynamically discover TypeCode for publications and subscriptions. It should be possible using builtin topics. I've used different examples (e.g. Example, HOWTO) from community site and got it working.
However I'm observing problems in following scenario:
- Create DomainParticipant
- Wait some time (10s)
- Lookup builtin DataReader for DCPSPublication and DCPSSubscription
- Wait for data and take it as soon it comes
In this case I get information only about DataReaders and DataWriters, which joined after initial delay of 10s. Already running DataReaders/Writers are not discovered. I assume that discovery happens during initial wait time and doesn't occur any more.
Is it possible to receive data on builtin topics again? Or is this data cached within DomainParticipant? (like discovered_topics and discoverd_participants)
I have attached monitoring application (tested locally with rti connext 5.1.0 on linux), which can be used to reproduce an error. Steps are:
- On the same host, default QoS settings.
- Start any publisher
- Start discovertypecodes
- Output doesn't contain typecode from the publisher
- Restart publisher from step 2
- Typecode of the publisher is received and printed
Thanks a lot in advance!
| Attachment | Size |
|---|---|
 discovertypecodes.c | 3.11 KB |
Hello Sergey,
In your code you are putting a sleep between the creation of the Domain paricipant and the call to
By doing that you are missing the dicovery information. The building subcribers are only created when the get_builtin_subscriber is called for the first time as explained here.
The rigth way to do this, is to create the domain participant disabled, get the built-int subscribers and then enable the participant.
Let me know if that works for you.
Best,
Gianpiero
Thank you for a quick response! Removing delay or enabling participant later works.
During my tests I had impression that some discovery data is lost when there are too many topics. Is it possible? I've checked QoS of DDS_PublicationBuiltinTopicDataDataReader and it's reliable and DDS_PublicationBuiltinTopicDataData has key, so no data should be lost, right? Or if any data was lost it happened between creation of domain participant and looking up builtin data reader?
Hi Sergey,
If the RTI core discovered the remote peer, then you should have access to the discovery data. Discovery data shouldn't be lost; it might not be received and require a retransmission before discovery completes, but again - if the RTI core discovers the peer, you should have access to the discovery data.
If you're not seeing some discovery traffic, it's likely because of your last question: discovery data that is processed between creating the participant and accessing the builtin subscriber. Your local participant sends out discovery announcements as soon as it's created, triggering discovery with any remote peers that are alive. Discovery may have already occurred between this happening and you registering a listener for the builtin topics.
Try creating the participant disabled, accessing the builtin subscriber, registering your listener, and then enabling the participant. Discovery announcements are not sent until the participant is enabled, and this approach should allow you to see all discovery traffic. You'll find code examples here (http://community.rti.com/examples/builtin-topics)
-sumeet
Hi Sumeet,
thank you for reply! Moving datareader lookup directly after domain participant creation solved the problem and I don't observe discovery data loss any more. If the problem comes later, I'll use creating disabled participant