RTPS
----
- Spec is DDS-RTPS v2.1
  - In this document, section numbers refer to RTPS v2.1 (formal/2010-11-01)
- Implemented as an OpenDDS pluggable transport + a new discovery mechanism
  - See RTPS_DISCOVERY in this directory for further discovery details
  - Note that transport and discovery mechanisms are separately configured
    - Any combination of discovery and transport should work together, but both
      RTPS transport and RTPS discovery are needed for interoperability
    - One exception: RTPS discovery with OpenDDS multicast, described below

Not Currently Implemented
-------------------------
(Items in this list are not necessarily needed for compliance or interop)
- Non-default LIVELINESS QoS (8.7.2.2.3 and 8.4.13)
- Writer-side content filtering (8.7.3)
  - OpenDDS may still drop samples that aren't needed (due to content filtering)
    by any associated readers -- this is done above the transport layer
- Coherent sets for PRESENTATION QoS (8.7.5)
- Directed writes (8.7.6) -- these don't exist in the DDS spec
- Property lists (8.7.7) -- these don't exist in the DDS spec
- Original writer info for DURABLE data (8.7.8) -- this would only be used for
  transient and persistent durability, which are not supported by the RTPS
  spec (8.7.2.2.1)
- Key Hashes (8.7.9) are not generated, but they are optional anyway
- wait_for_acknowledgements()
- nackSuppressionDuration (Table 8.47) and heartbeatSuppressionDuration
  (Table 8.62) are suggested but not described in the spec.  These may be
  useful areas for future enhancements.

Implementation Limits
---------------------
- (discovery) Domain IDs should be between 0 and 231 (inclusive) due to the way
  UDP ports are assigned to domain IDs.  In each OpenDDS process, up to 120
  domain participants are supported in each domain.
- Topic names and type identifiers are limited to 256 characters.

Migration Notes (InfoRepo discovery to RTPS discovery)
---------------
- DCPSInfoRepo-based discovery generates Built-In Topic data once (inside the
  info repo process) and therefore all known entities in the domain are
  reflected in the Built-In Topics.  RTPS discovery, on the other hand, follows
  the DDS specification and omits "local" entities from the Built-In Topics.
  The definition of "local" means those entities belonging to the same Domain
  Participant as the given Built-In Topic Subscriber.  Ignored entities will
  also be omitted from Built-In Topics when RTPS discovery is used.
- Topic Built-In Topic data is not propagated through RTPS discovery, it is
  optional in both DDS and RTPS specs.
- InfoRepo discovery makes the Data Writer's TRANSPORT_PRIORITY value known to
  the matched Data Readers.  RTPS discovery does not do this since it's not in
  the standard Built-In Topics.  It could be added at some point in the future
  with a vendor-specific ParameterId.

Implementation Issues
---------------------
- (discovery) Generated GUIDs could suffer from effects of PID rollover
- WRITER_DATA_LIFECYCLE (8.7.2.2.7) notes that the same Data submessage should
  dispose and unregister an instance.  OpenDDS may use two Data submessages.
- RTPS transport instances can not be shared by different Domain Participants.
- Transport auto-selection (negotiation) is partially supported with RTPS:
  the rtps_udp transport goes through a handshaking phase only in reliable mode.
- OpenDDS's native multicast transport does not work with RTPS Discovery due
  to the way GUIDs are assigned (a warning will be issued if this is attempted).

Notes for Maintainers
---------------------
- opendds_idl compiler has special support for custom RTPS Serialization
  - See dds/idl/marshal_generator.cpp
- OpenDDS_Dcps library has no RTPS-specific data types, only has limited support
  for RTPS features where necessary
- OpenDDS_Rtps library (in dds/DCPS/RTPS) has RTPS data types, constants,
  utility functions, and the Discovery implementation
- OpenDDS_Rtps_Udp library (in dds/DCPS/transport/rtps_udp) contains the the
  implementation of the OpenDDS pluggable transport for the RTPS UDP/IP PSM
