About

OpenDDS is an open-source C++ implementation of the Object Management Group's
specification "Data Distribution Service for Real-time Systems". Although
OpenDDS is itself developed in C++, Java and JMS bindings are provided so
that Java applications can use OpenDDS.

OpenDDS is built on the ACE
abstraction layer to provide platform portability. OpenDDS also leverages
capabilities of TAO, such as its IDL compiler
and as the basis of the OpenDDS DCPS Information Repository (DCPSInfoRepo).

The primary development of OpenDDS was done by the ACE/TAO development
team at Object Computing, Incorporated in
St. Louis and Phoenix. It is released under the same generous license
terms as ACE, TAO and MPC. See the LICENSE file for details.

OpenDDS is based on version 1.4 of OMG Data Distribution Service (DDS) for Real-Time Systems specification (formal/2015-04-10)
and version 2.2 of the Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDSI-RTPS) (formal/2014-09-01).

OpenDDS has been found to perform better than other TAO
services (notification and real-time event channel) by a factor of two
or three. The features offered by the Real-Time Event Channel and Notification Service are similar to DDS,
but not identical, so carefully examine your use-cases before choosing
one service over another. Speed is not the only criterion.

OpenDDS supports the following capabilities defined in the DDS Specification:

All profiles (including optional profiles) of the DCPS layer are implemented.

The Built-In Topic functionality is available and enabled by default. To disable
Built-in Topic support pass "-NOBITS" option to DCPSInfoRepo and "-DcpsBit 0" to all
clients.

Developers can define a structure in IDL that will be used as a DDS data type. The
structure may include basic scalar types, strings, sequences, arrays, enumeration and
unions. It may not contain interfaces or value types. Zero or more keys can be specified
for a data type.

Performance testing of OpenDDS can be performed using the OpenDDS-Bench
performance testing framework. This framework is currently located at:

$DDS_ROOT/performance-tests/Bench

in the OpenDDS source code distribution. Detailed information
about the OpenDDS-Bench framework is located at:

$DDS_ROOT/performance-tests/Bench/doc/userguide.html

Tests are configured
using files. The configuration files for some tests are included in
the OpenDDS distribution and can be used to repeat the testing
reported here in a user's environment. This way, users can compare
existing or other candidate data transport mechanisms in their
specific target environment to these results.
The test environments
include both OCI and customer test labs.

Some testing was performed in the OCI training laboratory.
These tests
are representative of performance in a busy, user-driven environment of
many desktop hosts with other tasks sharing the processing and network
resources along with the test execution. Testing in this environment
leads to noisy results, but demonstrates the performance of OpenDDS
under actual, adverse, conditions.

Additional testing was performed on a single, multi-core box.
While this configuration is unlikely to be commonly deployed, its
purpose is to establish the baseline behavior of OpenDDS in a
non-networked environment. Therefore, the latency numbers are those
that directly result from the running of the publisher and subscriber,
in different threads, on the same box, in loopback mode so as to
ensure that the entire transport stack is exercised.

This baseline behavior on a single host can, of course, be improved by
employing shared memory transport and other techniques. Therefore, the
performance characteristics reported in the single-host case do not
represent the lowest possible latency for OpenDDS. They are intended
to provide a reference measurement. For instance, testing with
various processor speeds shows that OpenDDS improves in almost a
directly proportional manner.
Further testing will be performed on boxes with faster processor speeds as they
become available to reaffirm this conclusion.

When OpenDDS is introduced into a more typical network setting, additional
latency will accrue, of course, depending on the network protocol, topology,
distance and network hardware, etc. In general, when measuring the latency in
networked settings, these other factors may well swamp the baseline results
seen here. The testing in the OCI training lab shows that latency might be
two to three times greater on a general purpose LAN. (See the actual results
of tests performed at "OCI Lab".)

Further performance testing will be performed on racked systems using
the standard protocols supported such as TCP/IP. This configuration is
increasingly commonly deployed for certain types of easily distributed
tasks that require close cooperation. The advertised latency between
boxes on Infinband,
for example, is a few hundred nanoseconds. (Other rack fabrics offer
similar numbers.) Therefore this should not cause much noticeable
additional latency. Testing will confirm this.

Comparison of the latency of OpenDDS with that of proprietary
offerings indicates OpenDDS performs about the same as the fastest of
its competitors. There is no advantage to be gained by purchasing a
proprietary implementation. The bottom line appears to be that when
using the open source DDS product, the savings from license fees can
be applied to network hardware, racks for co-located systems, etc. All
these investments will yield a commensurate return.