docs/design/RTPS

   1 RTPS
   2 ----
   3 - Initial implementation written to spec DDS-RTPS v2.1
   4   - In this document, section numbers refer to RTPS v2.1 (formal/2010-11-01)
   5 - Current version number is v2.2 (formal/2014-09-01)
   6   - See PROTOCOLVERSION in dds/DCSP/RTPS/BaseMessageTypes.h
   7   - No other changes are needed for v2.2 which is mostly editorial changes
   8   - All RTPS version 2.x implementations are designed to be interoperable
   9 - Implemented as an OpenDDS pluggable transport + a new discovery mechanism
  10   - See RTPS_DISCOVERY in this directory for further discovery details
  11   - Note that transport and discovery mechanisms are separately configured
  12     - Any combination of discovery and transport should work together, but both
  13       RTPS transport and RTPS discovery are needed for interoperability
  14     - One exception: RTPS discovery with OpenDDS multicast, described below
  15
  16 Not Currently Implemented
  17 -------------------------
  18 (Items in this list are not necessarily needed for compliance or interop)
  19 - Writer-side content filtering (8.7.3)
  20   - OpenDDS may still drop samples that aren't needed (due to content filtering)
  21     by any associated readers -- this is done above the transport layer
  22 - Coherent sets for PRESENTATION QoS (8.7.5)
  23 - Directed writes (8.7.6) -- these don't exist in the DDS spec
  24 - Property lists (8.7.7) -- these don't exist in the DDS spec
  25 - Original writer info for DURABLE data (8.7.8) -- this would only be used for
  26   transient and persistent durability, which are not supported by the RTPS
  27   spec (8.7.2.2.1)
  28 - Key Hashes (8.7.9) are not generated, but they are optional anyway
  29 - nackSuppressionDuration (Table 8.47) and heartbeatSuppressionDuration
  30   (Table 8.62) are suggested but not described in the spec.  These may be
  31   useful areas for future enhancements.
  32
  33 Implementation Limits
  34 ---------------------
  35 - (discovery) Domain IDs should be between 0 and 231 (inclusive) due to the way
  36   UDP ports are assigned to domain IDs.  In each OpenDDS process, up to 120
  37   domain participants are supported in each domain.
  38 - Topic names and type identifiers are limited to 256 characters.
  39
  40 Migration Notes (InfoRepo discovery to RTPS discovery)
  41 ---------------
  42 - DCPSInfoRepo-based discovery generates Built-In Topic data once (inside the
  43   info repo process) and therefore all known entities in the domain are
  44   reflected in the Built-In Topics.  RTPS discovery, on the other hand, follows
  45   the DDS specification and omits "local" entities from the Built-In Topics.
  46   The definition of "local" means those entities belonging to the same Domain
  47   Participant as the given Built-In Topic Subscriber.  Ignored entities will
  48   also be omitted from Built-In Topics when RTPS discovery is used.
  49 - Topic Built-In Topic data is not propagated through RTPS discovery, it is
  50   optional in both DDS and RTPS specs.
  51 - InfoRepo discovery makes the Data Writer's TRANSPORT_PRIORITY value known to
  52   the matched Data Readers.  RTPS discovery does not do this since it's not in
  53   the standard Built-In Topics.  It could be added at some point in the future
  54   with a vendor-specific ParameterId.
  55
  56 Implementation Issues
  57 ---------------------
  58 - (discovery) Generated GUIDs could suffer from effects of PID rollover
  59 - WRITER_DATA_LIFECYCLE (8.7.2.2.7) notes that the same Data submessage should
  60   dispose and unregister an instance.  OpenDDS may use two Data submessages.
  61 - RTPS transport instances can not be shared by different Domain Participants.
  62 - Transport auto-selection (negotiation) is partially supported with RTPS:
  63   the rtps_udp transport goes through a handshaking phase only in reliable mode.
  64 - OpenDDS's native multicast transport does not work with RTPS Discovery due
  65   to the way GUIDs are assigned (a warning will be issued if this is attempted).
  66 - opendds_idl generates key serialization in the order of the "#pragma
  67   DCPS_DATA_KEY" lines.  For structs with multiple keys, make sure that the
  68   order of the pragmas matches the order that any other DDS implementation uses
  69   to declare key fields in order to interoperate with that DDS implementation.
  70
  71 Notes for Maintainers
  72 ---------------------
  73 - opendds_idl compiler has special support for custom RTPS Serialization
  74   - See dds/idl/marshal_generator.cpp
  75 - OpenDDS_Dcps library has no RTPS-specific data types, only has limited support
  76   for RTPS features where necessary
  77 - OpenDDS_Rtps library (in dds/DCPS/RTPS) has RTPS data types, constants,
  78   utility functions, and the Discovery implementation
  79 - OpenDDS_Rtps_Udp library (in dds/DCPS/transport/rtps_udp) contains the the
  80   implementation of the OpenDDS pluggable transport for the RTPS UDP/IP PSM
  81
  82 Interoperability
  83 ----------------
  84 - In when sending AckNack submessages, OpenDDS used to insert INFO_REPLY
  85   submessages, but testing indicated that other DDS implementations didn't
  86   accept it.