I'm running NDDS 4.0i under Red Hawk on a Blade. I have two applications that are supposed to talk to each other via a simple one-topic protocol. My problem is that the applications may be very slow (tens of seconds) to recognize a publication_match or subscription_match. I may have one application that has matched both pub/sub and the other neither or only one of them.
Any ideas?
Hello stmarple,
I know that we made discovery performance improvements in the 4.2x era, but those mostly affected systems that were much larger.
Is this discovery over shared memory or over the network? Do both of your applications have consistent initial peers and transport settings?
Thank you!
Rose Wahlin
Hello
You may want to take a look at the this slow discovery forum thread. Specifically the response titled "Re: Discovery Time-- Potential Solution". It contains an example XML configuration thets the DomainParticipantQoS to improve discovery time. RTI DDS 4.0i did not support the use of XML to define QoS and we have made many improvements since then as Rose mentioned. However, while I am not completely sure, I think most of the settings that are defined in that "fast_dicovery" profile within that XML file are things that you can also configure directly using the C/C++ API my modifying the DomainParticipantQoS that you pass to the create_participant() operation.
Regards,
Gerardo
Rose, I'm communicating via network and using the default QoS settings. I should know exactly what you are talking about wrt initial peers and transport settings, but I don't. We are porting this application from a Sun system and it didn't really work there, though it was better. If I have one application up and then start the other one, the first one usually connects right away - within a second. This works regardless of which one starts first. If I kill and restart the second app, I can eventually get them both happy. I'm using a "launcher" to kick them off, so they typically start at the "same" time. So, I guess the problem is in the area of discovering with applications that are already running
A little more information: I am currently concerned only with one topic and its readers and writers as I'm trying to get my two simulation drivers working together. Once that is good, I will be using one of the simulation components to drive a target system with something on the order of 25 topics. Those readers and writers are being created now, but there isn't anything to match up with yet.
Thanks for the help thus far.
Ah, I have an idea of what might be wrong, if this is only happening after a restart of one of the applications:
I suspect that the application that is restarted is given the same GUID that it had before, which causes the new application to not realize this is a new, restarted application. We have a solution that talks about this. It specifies that this happens on VxWorks, but this can happen on other platforms if the process ID is being recycled when you shut down your application and restart.
http://community.rti.com/kb/why-my-vxworks-application-unable-discover-other-rti-connext-applications-after-restart
Thank you!
Rose
I'm off on travel for the next week, but I'll give this a go when I get back to the lab. It looks very promising.
Thanks again!