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 -- see java/README and java/jms/README
for details.

OpenDDS is built on the ACE (http://www.theaceorb.com/product/aboutace.html)
abstraction layer to provide platform portability.  OpenDDS also leverages
capabilities of TAO (http://www.theaceorb.com/), 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 (http://www.ociweb.com) 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.

This directory structure contains OpenDDS 3.5.1


======================================================================
* Documentation

The OpenDDS Developer's Guide is freely downloadable at:
http://download.ociweb.com/OpenDDS/

The TAO Developer's Guide book set may also be purchased from:
http://www.theaceorb.com/purchase/index.html


======================================================================
* Support

OCI strives to make OpenDDS as bug free as possible.  If you encounter
any problems with this release please fill out the PROBLEM-REPORT-FORM
file found in this directory and send to support@ociweb.com.

If you desire responsive commercial support for OCI on any problems
you encounter, we strongly recommend that you set up an account before
you actually need help.  There is no cost to establish a normal
account.  Support charges only apply to work actually delivered.
However, we do offer premium level accounts for customers with
specific support and enhancement needs, and there may be ongoing
charges for such premium service.  To set up a support account or to
find out more about the support options available, please contact
sales@ociweb.com.


======================================================================
* Features

This release of OpenDDS is based on the DDS Specification formal/07-01-01
(version 1.2).  It features the following transport protocols:

** TCP/IP
** UDP/IP
** IP multicast
** RTPS over UDP/IP (unicast and multicast)

RTPS (Interoperability) features are based on the DDS-RTPS Specification
formal/2010-11-01 (version 2.1).  See the OpenDDS Developer's Guide and
the file docs/design/RTPS for more details on RTPS.

OpenDDS has been found to perform better than other similar TAO
services (notification and real-time event channel) by a factor of two
or three.  The features offered by the RTEC and NS 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.

Currently OpenDDS does not support the Data Local Reconstruction Layer
(DLRL) portion of the DDS specification.  See the Developer's Guide for
further information on OpenDDS compliance with the DDS specification.
This document is freely available as a PDF file
from the same location where OpenDDS can be downloaded.  Some
additional notes about compliance with the DDS specification can be
found below.  If you would like have OCI add a feature to OpenDDS
please see the Support section for contact information.


======================================================================
* Dependencies

** TAO

OpenDDS requires TAO for both IDL compilation as well as interaction
with the DCPSInfoRepo.  If you will be using the "configure" script for OpenDDS
(see the INSTALL file for details), you do not need to download TAO first --
the "configure" script will download it for you.

At a minimum, you must be at one of the following versions in order to properly
compile OpenDDS:

*** TAO 1.6a patch 14
*** TAO 2.0a patch 7
*** TAO 2.2.0a
*** TAO 2.2.4 (DOC Group)

Note that the 1.6a, 2.0a, and 2.2a releases are from OCI and can be obtained
from http://www.theaceorb.com/.  The DOC Group releases can be obtained from
http://download.dre.vanderbilt.edu/.

** GNU Make

GNU Make 3.80+ was used for automating the compiling and linking of OpenDDS
on Unix and Linux systems.

** Perl

Perl is used for running the automated tests and examples included in this
source tree, or if you will be generating Makefiles or Visual Studio project
files.  In most cases you will *not* need to generate Makefiles/project files
for OpenDDS itself (but see the INSTALL file for details), but doing so for
your own application code that uses OpenDDS is recommended.  On Windows we
recommend the use of ActiveState Perl.  The "configure" script also uses Perl.

* Build Targets

* Operating Systems

This release of OpenDDS has been tested under the following platforms:

Linux family:
** Red Hat EL 5, x86_64
** Red Hat EL 6.2, x86_64
** Fedora Core 6, x86
** Fedoras 12, 15, and 17, x86_64
** Ubuntu 12.04 LTS, x86_64
** openSUSE 11.4, x86_64
** openSUSE 12.2, x86_64

Windows family:
** Windows XP
** Windows Server 2003
** Windows 7 (64-bit)
** Windows Server 2008 R2 (64-bit)
** Windows Mobile 6 (ARM)

Others:
** Android NDK
** SunOS 5.10 (Solaris 10) (SPARC)
** SunOS 5.11 (OpenSolaris 2009.06) (x86)
** QNX Neutrino 6.3.2 (x86)
** Macintosh OS X 10.6 "Snow Leopard" (x86)
** VxWorks 6.9 RTP (x86) -- compiled but not yet tested


======================================================================
* Compilers

This release of OpenDDS has been tested using the following compilers:

** Microsoft Visual C++ 7.1 with SP1 (Visual Studio .NET 2003)
** Microsoft Visual C++ 8 with SP1 (Visual Studio 2005)
** Microsoft Visual C++ 9 with SP1 (Visual Studio 2008)
** Microsoft Visual C++ 10 with SP1 (Visual Studio 2010)
** Microsoft Visual C++ 11 (Visual Studio 2012 / nmake projects)
** gcc 4.1.x
** gcc 4.2.1 (Apple Inc. build 5646 dot 1)
** gcc 4.4.x
** gcc 4.5.x
** gcc 4.6.x
** gcc 4.7.x
** gcc 4.8.x
** Clang 3.2
** QNX gcc 3.3.5
** Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
** Sun C++ 5.10 SunOS_i386 2009/06/03

* Building and Installing

For building and installation instructions
see the INSTALL file in this directory.


======================================================================
* OpenDDS Compliance with the DDS Specification

See http://www.opendds.org and the OpenDDS Developer's Guide at:
http://download.ociweb.com/OpenDDS/OpenDDS-latest.pdf


======================================================================
* Known Limitations (WARNING: some of these may be out of date)

----------------------------------------------------------------------
) An instance key must be a base type (not a complex type like array or
  struct).

  This limitation exists because the generated lessThan operator does
  not currently handle complex types.

  This limitation can be worked around by specifying multiple keys such
  that all of the base types in the complex type are specified.

----------------------------------------------------------------------
) Users must ensure that TopicDescriptions are not used after the
  associated Topic is deleted.

----------------------------------------------------------------------
) create_datawriter() does not wait for full association establishment;
  a write shortly after creating the datawriter may be dropped on
  the publisher side because add_associations() has not yet completed.

  The sample may also be dropped on the subscriber side even though
  the connection exists between the publisher and subscriber when
  the associations have not yet been mapped.

  If the publisher expects existing DataReaders to receive the
  messages it sends after creating the DataWriter, it must wait for
  full association before writing messages.

  You may perform the following to avoid message loss during association
  for an expected quantity of associated DataReaders:

    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);


  Note: DDS by its nature is not connection oriented.  That is, publication
        and subscription lifecycles are decoupled.  A number of QoS policies
        exist which help manage late joining readers and writers
        (i.e. DURABILITY).  For more information, please review the various
        QoS policies documented in the OpenDDS Developer's Guide.

----------------------------------------------------------------------
) Samples are only rejected for having more than
  qos.resource_limits.max_samples_per_instance NOT_READ samples in an
  instance.

  The implementation should also reject for too many total NOT_READ
  samples or too many instances.

  Since the OpenDDS implementation does not have hard limits with
  respect to these values this limitation is considered acceptable.

  Note: When more than resource_limits.max_samples are queued
  in the DataReader the heap will be used instead of pre-allocated
  memory.

----------------------------------------------------------------------
) The DURABILITY_SERVICE service_cleanup_delay support is currently
  experimental.  The corresponding DURABILITY service_cleanup_delay
  support is not available.

----------------------------------------------------------------------
) There is unspecified behavior when a non-volatile DataWriter persists
  samples belonging to an outstanding coherent change group.  The coherent
  samples are not persisted, however their presence may prematurely evict
  valid data samples from the durability cache due to resource limits.

  Coherent change groups are not maintained when their constituent data
  is persisted.  When a non-volatile DataWriter comes online, samples
  previously sent as a part of a change group will no longer maintain
  their atomicity.

----------------------------------------------------------------------
) The multicast transport design documentation maintains its own set of
  known issues; see: $DDS_ROOT/docs/html/multicast/multicast.html.


======================================================================
* Test Failures

** tests/DCPS/Thrasher

  The Thrasher test is designed to stress resource allocation/deallocation
  in running systems.  These tests are expected to fail given insufficient
  resources.

** multicast

  Tests using the multicast transport fail on QNX hosts due to problems with
  IP multicast loopback.  These tests are disabled in the nightly automated
  build/test for these hosts.

Note: A list of tests that are run in the nightly automated build/test
      can be found in $DDS_ROOT/bin/dcps_tests.lst