Hello.
I have been going through the C documentation for Connext DDS Pro 5.3.1 and have been trying to understand the addressing mechanism that DDS uses for service discovery and the way in which it communicates with underlaying Transport layer.
Questions:
1. What is the difference between rtps_instance_id and participant id?
2. In the documentation, they refer to GUID as (GUID Prefix + Entity ID). Is this Entity ID same as the participant_id ?
MQTT provides a "Last Will & Testament" QoS, that causes a writer to emit a final instance when it it shuts down, effectively a shut-down hook.
I want to implement the same thing using DDS {in Java*}. I'm looking for different ideas on what might be a best-practice...
I want to avoid writing my own manual shutdown algorithm (I want to call <participant>.delete_contained_entities(), and have that trigger a final sample being published).
At the moment I'm subclassing the data writer:
I have been interested in some inter-operability issues that I have seen between RTI and OpenDDS. I am posting this here and will also cross post/email to OpenDDS community. By no means do I claim that interoperability problems exist due to RTI's fault (or anyone's fault.) (What I see could very well be due to some programming oversight on my part.)
Hello:
I am new to RTI but somewhat familiar w/ DDS and middleware concepts. I have been able to download RTI and build and run the example under:
~/rti_workspace/5.2.0/examples/connext_dds/c++/hello_simple/objs/i86Linux3gcc4.8.2
I have two programs -- I'll call them REQUESTER and RESPONDER. The REQUESTER sends a request DDS message to the RESPONDER and, in the DDS callback, the RESPONDER sends back 88 small messages in a tight loop. Once the RESPONDER sends the messages it exits. When the REQUESTER receives all 88 messages it exits. However, the REQUESTER only gets the first 32 messages and waits for the others. The RESPONDER exits as expected after sending all 88.
If I put a 10ms sleep between each response message all 88 are received.
