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 2.2.


======================================================================
* 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

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.  In addition, support for some
Quality of Service policies is not currently available in OpenDDS.  See
the Developer's Guide for further information on OpenDDS compliance with
the DDS specification.  This chapter 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.5a patch 21
*** TAO 1.6a patch 7
*** TAO 1.8.1 (DOC Group)

Note that the 1.5a and 1.6a 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,
but see the INSTALL file for details.  On Windows platforms, 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:
** RedHat EL 5, x86_64
** Fedora Core 6, x86
** CentOS 5, x86_64
** Ubuntu 8.04 LTS, x86_64
** Ubuntu 8.10, x86

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

Others:
** SunOS 5.9 (Solaris 9) (x86)
** SunOS 5.10 (Solaris 10) (SPARC)
** SunOS 5.11 (OpenSolaris 2009.06) (x86)
** QNX Neutrino 6.3.2 (x86)
** Macintosh OS X 10.5 "Leopard" (x86)
** VxWorks 6.8 RTP (x86) -- compiled but not yet tested


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

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

** Microsoft Visual C++ 7.1 (Visual Studio .NET 2003)
** Microsoft Visual C++ 8 with SP1 (Visual Studio 2005)
** Microsoft Visual C++ 9 with SP1 (Visual Studio 2008)
** gcc 3.3.2
** gcc 4.0.1 (Apple Inc. build 5465)
** gcc 4.1.1 (Red Hat 4.1.1-30) (Red Hat 4.1.1-52)
** gcc 4.1.2 (Red Hat 4.1.2-14)
** gcc 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
** gcc 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
** gcc 4.5.1
** QNX gcc 3.3.5
** Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
** Sun C++ 5.9 SunOS_i386 Patch 124864-07 2008/08/22
** Sun C++ 5.10 SunOS_i386 2009/06/03

* Building and Installing

For building and installation instructions see INSTALL.


======================================================================
* 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

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

----------------------------------------------------------------------
) There is no check that the Transport implementation supports the
  given QoS.  The user should not use the udp transport with
  RELIABILITY.kind = RELIABLE.

----------------------------------------------------------------------
) 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.  Any failure reported above the `low' threshold should not be
  considered a true test failure.

** 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
