OpenDDS FAQ
| |
Q: |
What's a PRF? |
A: |
"PRF"
refers to the PROBLEM-REPORT-FORM, i.e., $DDS_ROOT/PROBLEM-REPORT-FORM.
The odds of getting questions answered, bugs fixed, etc., goes up significantly when you report problems using the PRF because it insures that developers and support personnel get the most commonly required information right away. Failure to use the PRF means that those folks have to spend valuable time (yours and theirs) having a conversation to get that information just to start debugging. Unless you've got a paid support contract, there's even a chance that nobody will answer!
So, always use the PRF!
|
Q: |
Is there a mailing list or forum or usenet group for discussion of OpenDDS ? |
A: |
Yes. The DDS mailing lists are available through the
OpenDDS SourceForge
project page. The archives of previous messages are searchable.
Please remember to use the Problem Report Form (See What's a PRF?) when
posting questions (and not just "problems").
|
Q: |
What will the Navy SBIR award activity focus on? |
A: |
See the Navy SBIR Award summary.
|
Q: |
Which platforms does OpenDDS support? |
A: |
Please refer to the Building OpenDDS
documentation for a complete list of supported platforms.
|
Q: |
Is OpenDDS interoperable with other DDS implementations? |
A: |
Currently no. OpenDDS currently doesn't have an implementation of RTPS (Real Time Publish-Subscribe) transport layer required for interoperability.
This capability is only required in environments with mixed implementations. OCI has made substantial changes to those areas within OpenDDS that would be impacted by the addition of the Interoperability Wire Protocol Specification. This has reduced the work required to add this capability. If you wish to sponsor or discuss this activity email sales@ociweb.com. |
Q: |
How does OpenDDS use CORBA? |
A: |
OpenDDS uses CORBA to administer and control the establishment of data connections. CORBA is not used in the distribution of application data.
Because of shared characteristics between CORBA and DDS, and particularly because of TAO and OpenDDS's shared lineage CORBA can be easily integrated into an OpenDDS environment and vice versa. Together they provide synergism. See the OCI Middleware NewsBriefs where OCI will feature discussions on DDS and CORBA technologies. |
Q: |
Summarize the network connections established by OpenDDS in a two participant scenario? |
A: |
Two participants (one only publishes and the other only subscribes) using TCP with no BITs. Here we would expect to see three established TCP connections at each participant:
|
| |
Q: |
How do I obtain, configure, and build OpenDDS? |
A: |
Please refer to the Building OpenDDS documentation for complete requirements and build steps.
|
Q: |
Why the tao_idl generated stub code did not define *KeylessThan struct ? |
A: |
The *KeylessThan struct is DCPS specific code, the -Gdcps needs be
passed to tao_idl command line to generate those specific code.
e.g. $(ACE_ROOT)\bin\tao_idl -Gdcps -I$(DDS_ROOT) Messenger.idl |
Q: |
What could be causing std lib related build failures on Linux? |
A: |
OpenDDS makes more extensive use of the C++ standard library, compared to ACE+TAO. You may be uncovering issues that ACE+TAO may have managed to avoid.
We have seen gcc 4.0.x-series compiler users to hit this problem more often. The visibility feature in this compiler still seems to be in a state of flux. We therefore recommend turning it off by adding "no_hidden_visibility=1" to your platform_macros.GNU file.
|
Q: |
When building OpenDDS I get warnings reporting that the environment variable OPENDDS_DCPS_TS_FLAGS was not found. What gives? |
A: |
This warning most often presents itself when building using Visual C++
compilers; it may safely be ignored.
|
| |
Q: |
Why "SimpleTcp" is not automatically registered ? |
A: |
Starting with the 0.11 release, the SimpleTcp transport was separated the from DCPS core library to reduce footprint. Please see the section on "Pluggable Transports" in the DDS DevGuide (http://download.ociweb.com/OpenDDS/OpenDDS-latest.pdf)
for how to load the SimpleTcp library.Or you can look at the $DDS_ROOT/DevGuideExamples/DDS/Messenger example. Test script "run_test.pl" runs the test
with SimpleTcp transport configuration.
On a related note the DCPSInfoRepo uses the SimpleTcp transport
solely to transmit BIT (Built In Topics) information. If your
application isn't subscribing to BITS, then the InfoRepo doesn't
need the transport library. Just start up the InfoRepo with the
-NOBITS option and you will be OK.
|
Q: |
Does OpenDDS support broadcast or multicast? If so, how do you set it up? |
A: |
Reliable multicast has been available in OpenDDS since the
0.12 release (unreliable multicast since 0.11 release). A broadcast based transport is currently not available. Please see the section on "Pluggable Transports" in the DDS DevGuide (http://download.ociweb.com/OpenDDS/OpenDDS-latest.pdf) for how to setup using the unreliable multicast transport. Or you can look the $DDS_ROOT/DevGuideExamples/DDS/Messenger. The "run_test.pl mcast" runs the test with SimpleMcast transport configuration.
|
Q: |
Why did a subscriber did not receive all samples sent by the publisher? |
A: |
While there can be multiple reasons that the samples are lost or dropped, a common
problem is that the publisher starts sending samples before the subscriber is
ready to receive. To synchronize, the publisher can use a WaitSet before writing.
This ensures the subscriber is ready to receive samples. Here is the example code.
DDS::StatusCondition_var cond = writer->get_statuscondition();
cond->set_enabled_statuses(DDS::PUBLICATION_MATCHED_STATUS);
DDS::WaitSet_var ws = new DDS::WaitSet;
ws->attach_condition(cond);
DDS::Duration_t timeout =
{ DDS::DURATION_INFINITE_SEC, DDS::DURATION_INFINITE_NSEC };
DDS::ConditionSeq conditions;
DDS::PublicationMatchedStatus matches = { 0, 0, 0, 0, 0 };
do {
if (ws->wait(conditions, timeout) != DDS::RETCODE_OK) {
// failure
}
if (writer->get_publication_matched_status(matches) !=
DDS::RETCODE_OK) {
// failure
}
} while (matches.current_count < 1);
ws->detach_condition(cond);
|
Q: |
Why can't my publisher establish a connection with a remote subscriber? |
A: |
While there can be multiple reasons for inter-host communication
failure, this entry deals with connection establishment failures
due to improper endpoint configuration.
The configuration option "local_address" represents the endpoint address.
This host/port tuple is used by the publisher to initiate connection
establishment. In order to allow inter-host communication, make sure the
endpoint address is publicly visible.
A common mistake is to re-use the configuration provided in the
exercises without modifications. Since the examples are intended to
be run on an intra-host environment, they generally use the 'localhost'
interface. This configuration will fail when the test is run in an
inter-host setting.
|
| |
Q: |
What is the status of BIT support in OpenDDS? |
A: |
Support for Built-In-Topics is complete since the 0.12 release. This means that BITs will now work as specified. BIT support is now turned on by default.
BIT associates are created via TCP and therefore require support of the SimpleTcp transport library. When using BITs make sure the SimpleTcp transport has been properly configured in both the InfoRepo as well as the participants.
|
Q: |
How do I turn off BIT support at build-time? |
A: |
It is possible to build OpenDDS without BIT support which will reduce overall footprint. For this you will need to generate new project files:
mwc.pl -type <yourtype> -features built_in_topics=0 DDS.mwc
If <yourtype> happens to be gnuace, add "built_in_topics=0" to the
platform_macros.GNU file or the MAKEFLAGS environment variable.
|
Q: |
How do I turn off BIT support at run-time? |
A: |
Turning off BIT support involves it being turned off in the DCPS Information Repository and any associated participants.
The DCPSInfoRepo option -NOBITS disables BIT support for the InfoRepo. The option '-DCPSBit 0' will disable BIT support for all participants in the process.
|