2.1. General Compatibility 6.1.0¶
This section describes compatibility issues that affect the Connext suite in Release 6.1.0. Unless noted otherwise, the issues in this section do not apply to Connext DDS Micro.
220.127.116.11. New and Removed Platforms¶
18.104.22.168. Additional Build Flags for Backtrace Feature¶
Additional build flags, including
-rydynamic, are now required for a proper debug
build using the backtrace feature. (Backtrace support was added in 6.0.1 and
enhanced in 6.1.0.) If these flags are not included, some details
like the line number associated with each stack frame may not be available.
For further details, look for “Backtrace Support” for your operating system in the
Core Libraries Platform Notes.
22.214.171.124. VxWorks Installation Changes¶
In previous releases, VxWorks® libraries came in one target package, such as
rti_connext_dds-6.0.1-pro-target-pentium64Vx6.9gcc4.3.3.rtipkg. In this release,
the VxWorks targets come in separate files, one for the kernel libraries and
one for the rtp libraries:
The rtp libraries are now packaged/installed separately from the kernel package.
126.96.36.199. VxWorks Library Name Changes¶
In VxWorks rtp architectures, the names of the utilities are now suffixed with a
“z” to indicate that they are statically linked: RTI DDS Ping is called
rtiddspingz.vxe, RTI DDS Spy is called
rtiddsspyz.vxe, and RTI DDS
Prototyper is called
For more information, see Using DDS Ping and Spy, in the Getting Started Guide Addendum for Embedded Systems.
2.1.2. Wire Compatibility¶
188.8.131.52. RTPS Versions¶
See Section 184.108.40.206 for information about the RTPS versions supported for each Connext DDS release.
220.127.116.11. Protocol Changes¶
18.104.22.168.1. New RTPS BINDING_PING submessage when using RTI Real-Time WAN Transport¶
Real-Time WAN Transport uses special RTPS messages called BINDING_PING messages
to open NAT bindings and to resolve endpoint locators into public IP transport
addresses. These messages are sent periodically at a period configured by the
For additional information, see RTI Real-Time WAN Transport, in the RTI Connext DDS Core Libraries User’s Manual.
22.214.171.124.2. Changes to PID_DIRECTED_WRITE inline QoS parameter¶
The OMG RTPS 2.3 specification defines the GUID in a PID_DIRECTED_WRITE inline QoS parameter as a <GUID_t>. Previous releases incorrectly serialized the GUID as four integers in native endianness, as opposed to an array of 16 bytes. To conform with the specification, Connext DDS now serializes the GUID as an array of 16 bytes.
To avoid breaking backward compatibility with previous releases, the GUID is still serialized natively when the remote DomainParticipant has an older Connext DDS product version.
126.96.36.199.3. New DATA_FRAG_SESSION submessage when using fragmentation with MultiChannel DataWriters¶
MultiChannel DataWriters (including DataWriters of TopicQuery samples) send fragmented data using a new RTPS submessage called DATA_FRAG_SESSION (submessage ID: 0x81). It is similar to DATA_FRAG, except that there is an additional virtual sequence number field in the submessage.
This protocol change breaks compatibility with previous releases. A DataReader in a previous release cannot receive MultiChannel or TopicQuery RTPS fragmented data from a DataWriter in 6.1.0. See Section 188.8.131.52 for additional information.
184.108.40.206.4. New bit in PID_VENDOR_BUILTIN_ENDPOINT_SET sent with DATA(P) messages¶
This release introduces a new bit, RTPS_VENDOR_BUILTIN_ENDPOINT_CDS_ANNOUNCER_WRITER (0x00000001 << 6), into the PID_VENDOR_BUILTIN_ENDPOINT_SET parameter sent with DATA(P) messages to indicate that the DATA(P) message is coming from Cloud Discovery Service.
220.127.116.11.5. Extension to DATA_REPRESENTATION PID¶
The compression QoS settings are included as part of the
and are used for endpoint matching during discovery. In general, Connext DDS attempts to
save bandwidth during endpoint discovery by only propagating QoSs that are set differently
from an assumed default value. In the case of
compression_ids, if they are not sent
during endpoint discovery, the assumed default is that the endpoint (DataWriter or DataReader) does
not support any compression algorithms. The default setting for a DataReader, however, is to
support all available builtin compression algorithms, meaning that the
and therefore the entire DataRepresentationQosPolicy, is sent by default in the
SubscriptionBuiltinTopicData. This adds an additional 16 bytes to the
SubscriptionBuiltinTopicData by default. Setting a DataReader’s
COMPRESSION_ID_MASK_NONE gets rid of these additional bytes.
compression_ids are sent to endpoints (DataWriters and DataReaders) during discovery, the
additional number of bytes sent is as follows:
4 bytes for the QoS mutable header:
2 bytes for parameterId
2 bytes for parameterLength
6 bytes for the struct DDS_DataRepresentationIdSeq value:
4 bytes of sequence length
2 bytes of default sequence value (short integer)
2 bytes for padding
4 bytes for DDS_CompressionIdMask
TOTAL = 16 Bytes
18.104.22.168.6. New inline QoS Parameters for coherent set samples¶
6.1.0 introduces support for coherent access with group presentation (see What’s New in 6.1.0). This feature adds the following inline parameters sent with samples that are part of a coherent set:
PID_END_COHERENT_SET (0x8022): Vendor-specific parameter associated with an end coherent set sentinel sample. This parameter contains the sequence number of the first sample update belonging to the coherent set from the DataWriter publishing the sample. The size of this parameter is 12 bytes.
PID_GROUP_COHERENT_SET (0x0063): Contains the group sequence number of the first sample update belonging to the coherent set across all DataWriters within the Publisher. The size of this parameter is 12 bytes.
PID_END_GROUP_COHERENT_SET (0x8023): Vendor-specific parameter associated with an end coherent set sentinel sample. This parameter contains the sequence number of the first sample update belonging to the coherent set across all DataWriters within the Publisher. The size of this parameter is 12 bytes.
PID_END_COHERENT_SET_SAMPLE_COUNT (0x8024): Vendor-specific parameter associated with an end coherent set sentinel sample. This parameter contains the number of samples contained in the coherent set for a DataWriter. The size of this parameter is 8 bytes.
22.214.171.124. DataReader in previous release cannot receive MultiChannel or TopicQuery RTPS fragmented data from DataWriter in 6.1.0¶
The fix for RTI Issue ID CORE-9335 required breaking backward compatibility with the existing support for RTPS data fragmentation with MultiChannel and TopicQuery. This means that you will not be able to have a DataReader from a previous release receiving MultiChannel or TopicQuery RTPS fragmented data from a 6.1.0 DataWriter.
2.1.3. Type System Compatibility¶
126.96.36.199. Connext DDS applications from previous releases will not interoperate with 6.1.0 and later, for types containing optional primitive members, when data representation is XCDR2¶
In previous releases, a bug (RTI Issue IDs CORE-10254 and MICRO-2307) led to an incorrect XCDR2 serialization of samples for a type with the following properties:
The type had a primitive member ‘Pn’ (it could be external but not optional) following another primitive member ‘Pn-1’ that was marked as optional.
The required alignment for ‘Pn’ was smaller than or equal to the required alignment for ‘Pn-1’.
The optional member was set to NULL in the sample.
This issue affected both Connext DDS Micro and Connext DDS Professional. It affected the following language bindings: C, C++ (traditional and modern), and DynamicData in all languages. It affected all languages if using ContentFilteredTopics.
After fixing this issue, Connext DDS applications from before 6.1.0 will not interoperate with Connext DDS applications 6.1.0 and later, for Topics using the types with the properties described above.
188.8.131.52. C/C++ applications may not interoperate for keyed types under certain conditions¶
In previous releases, a bug (RTI Issue IDs CORE-11290 and MICRO-2987) led to an incorrect XCDR (Extensible CDR version 1) instance keyhash generation for C/C++ applications.
This issue only occurred when:
The type was a keyed type containing a key member whose type was a typedef of a keyed struct/valuetype type.
The data representation was XCDR (Extensible CDR version 1).
You generated code using the command-line option
This issue affected both Connext DDS Micro and Connext DDS Professional. It affected the following language bindings: C, C++ (traditional and modern).
After fixing this issue, C/C++ Connext DDS applications from before 6.1.0 will not
fully interoperate with Connext DDS applications 6.1.0 and later, for Topics using
the types with the properties described above. As a result, the subscribing
application may observe some unexpected behavior related to instances. Specifically,
the call to
DataReader::lookup_instance() might fail and return
even if the instance was received.
2.1.4. Transport Compatibility¶
184.108.40.206. IP Mobility events may stop communication with applications from previous releases¶
In previous releases, IP mobility events that qualified as a change (for example, the change of the IP address of one of the local interfaces) always triggered the sending of both Participant and Endpoint discovery updates to all the matched remote entities. This was true even in scenarios where, due to the nature of the change, it was enough just to send Participant Discovery updates—for example, when DataWriters and DataReaders were using the default Participant locators (as opposed to setting specific locators through TransportSelection or TransportUnicast QoS policies).
This release changes the behavior of Connext DDS in this scenario: a Participant will now only send Participant Discovery updates, saving the network bandwidth associated with sending Endpoint Discovery updates. Connext DDS will still propagate Endpoint Discovery updates in scenarios where DataWriters and DataReaders are using specific locators instead of the ones inherited from the Participant.
This change breaks backwards compatibility with pre-6.1.0 versions of Connext DDS once an IP mobility change occurs. Previous versions of Connext DDS still need to receive the redundant Endpoint Discovery traffic to process the change.
For backwards compatibility, set the property
to true in 6.1.0.
2.1.5. XML Compatibility¶
220.127.116.11. Summary of XML schema changes for XML-based application creation and QoS profiles¶
Release 6.1.0 introduces some changes to the XML schema for Connext DDS applications that can break XML configurations from previous releases. Table 2.1 lists the changes, which are described in more detail below.
Comma-separated decimal or hexadecimal element values for
The following tags …
were renamed …
18.104.22.168. Use new XML tag names <participant_qos>, <filter>, and <parameter_list>¶
Some XML tags were renamed to make the schema compliant with the latest DDS-XML specification:
The old tags are still accepted by the Connext XML parser and the XSD schema to maintain backward compatibility. However, you should transition to the new tags.
This issue also affects the Micro Application Generator (MAG).
22.214.171.124. Instance replacement changes affect XML files in Micro Application Generator (MAG)¶
This issue only affects XML files used by Micro Application Generator (MAG) for use
in Connext DDS Micro. The issue affects only MAG because the
tag was added in 6.0.1 for MAG, but it is new in 6.1.0 for the Connext DDS
(See Configure how instances will be replaced …, in What’s New in 6.1.0.)
As a result of this new functionality in the Core Libraries, the type used by
<instance_replacement> in MAG has been changed from a single type to a complex type.
Because of this change, XML files used by MAG in previous releases won’t work out of
the box in 6.1.0. For example, the following XML worked in 6.0.1 in MAG, but will not
<datareader_qos> <reader_resource_limits> <instance_replacement>OLDEST_INSTANCE_REPLACEMENT</instance_replacement> </reader_resource_limits> </datareader_qos>
To work in 6.1.0, change the above XML to the following:
<datareader_qos> <reader_resource_limits> <instance_replacement> <alive_instance_removal>ANY_INSTANCE_REMOVAL</alive_instance_removal> <disposed_instance_removal>ANY_INSTANCE_REMOVAL</disposed_instance_removal> <no_writers_instance_removal>ANY_INSTANCE_REMOVAL</no_writers_instance_removal> </instance_replacement> </reader_resource_limits> </datareader_qos>