forked from OpenDDS/OpenDDS
-
Notifications
You must be signed in to change notification settings - Fork 0
/
RTPS
86 lines (80 loc) · 4.69 KB
/
RTPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
RTPS
----
- Initial implementation written to spec DDS-RTPS v2.1
- In this document, section numbers refer to RTPS v2.1 (formal/2010-11-01)
- Current version number is v2.2 (formal/2014-09-01)
- See PROTOCOLVERSION in dds/DCSP/RTPS/BaseMessageTypes.h
- No other changes are needed for v2.2 which is mostly editorial changes
- All RTPS version 2.x implementations are designed to be interoperable
- 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)
- 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
- 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).
- opendds_idl generates key serialization in the order of the "#pragma
DCPS_DATA_KEY" lines. For structs with multiple keys, make sure that the
order of the pragmas matches the order that any other DDS implementation uses
to declare key fields in order to interoperate with that DDS implementation.
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
Interoperability
----------------
- In when sending AckNack submessages, OpenDDS used to insert INFO_REPLY
submessages, but testing indicated that other DDS implementations didn't
accept it.