4.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 Micro.
Attention
For important information on new and removed platforms and features in 6.1.0, see What’s New in 6.1.0. See also individual products’ Release Notes.
4.1.1. Platforms
4.1.1.1. Linking static Linux or QNX libraries with object files built with -fPIC will fail
In 6.1.0, RTI no longer builds Linux or QNX static libraries with the -fPIC
flag
(whereas previously RTI did build with this flag). Therefore, you cannot
link Linux or QNX static libraries in 6.1.0 with object files built with the -fPIC
flag. You will likely run into this problem if you use the static Linux or QNX library
in 6.1.0 while building a shared library.
This problem is fixed in release 6.1.1. See Potential -fPIC flag issue when using static libraries in Linux and QNX if upgrading from 6.1.0.
4.1.1.2. New Linux® Linker Flag
For GCC 6 or higher, there is a new required linker flag for compiling:
-no-pie
. See the “Building Instructions for Linux Architectures” table in the
Core Libraries Platform Notes for more information.
4.1.1.3. 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.
4.1.1.4. 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:
rti_connext_dds-6.0.1-pro-target-pentium64Vx6.9gcc4.3.3.rtipkg
for kernelrti_connext_dds-6.0.1-pro-target-pentium64Vx6.9gcc4.3.3_rtp.rtipkg
for rtp
The rtp libraries are now packaged/installed separately from the kernel package.
4.1.1.5. 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 rtiddsprototyperz.vxe
.
For more information, see Using DDS Ping and Spy, in the Getting Started Guide Addendum for Embedded Systems.
4.1.1.6. Android Static Libraries no Longer Supported
Starting in 6.1.0, RTI no longer supports Android™ static libraries. Android dynamic libraries are still supported.
4.1.2. Wire Compatibility
4.1.2.1. RTPS Versions
For information about the RTPS versions supported for each Connext release, see Compatibility in the RTI Connext Core Libraries Release Notes for 7.3.0 LTS.
4.1.2.2. Protocol Changes
4.1.2.2.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
parameter <binding_ping_period>
, in <transport_builtin>/<udpv4_wan>
.
For additional information, see RTI Real-Time WAN Transport, in the RTI Connext Core Libraries User’s Manual.
4.1.2.2.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 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 product version.
4.1.2.2.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.
Important
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 4.1.2.3 for additional information.
4.1.2.2.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.
4.1.2.2.5. Extension to DATA_REPRESENTATION PID
The compression QoS settings are included as part of the
DATA_REPRESENTATION QosPolicy
and are used for endpoint matching during discovery. In general, Connext 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 compression_ids
,
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_ids
to
COMPRESSION_ID_MASK_NONE
gets rid of these additional bytes.
When 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
compression_ids
(dds ulong)
TOTAL = 16 Bytes
4.1.2.2.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.
4.1.2.3. 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.
4.1.3. Type System Compatibility
4.1.3.1. Connext 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 Micro and Connext 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 applications from before 6.1.0 will not interoperate with Connext applications 6.1.0 and later, for Topics using the types with the properties described above.
4.1.3.2. 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
-optimization 0
.
This issue affected both Connext Micro and Connext Professional. It affected the following language bindings: C, C++ (traditional and modern).
After fixing this issue, C/C++ Connext applications from before 6.1.0 will not
fully interoperate with Connext 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 HANDLE NIL
even if the instance was received.
4.1.4. Transport Compatibility
4.1.4.1. 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 in this scenario: a Participant will now only send Participant Discovery updates, saving the network bandwidth associated with sending Endpoint Discovery updates. Connext 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 once an IP mobility change occurs. Previous versions of Connext still need to receive the redundant Endpoint Discovery traffic to process the change.
For backwards compatibility, set the property
dds.participant.discovery_config.force_endpoint_announcement_on_ip_mobility_event
to true in 6.1.0.
4.1.5. XML Compatibility
4.1.5.1. 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 applications, some of which can break XML configurations from previous releases. Table 4.1 lists the changes, which are described in more detail below.
Pre-6.1.0
6.1.0
See …
Comma-separated decimal or hexadecimal element values for
<group_data>
,<user_data>
, and<topic_data>
xs:hexBinary
format for<group_data>
,<user_data>
, and<topic_data>
<participant_qos>
<domain_participant_qos>
<filter>
<content_filter>
<parameter_list>
in<filter>
<expression_parameters>
in<content_filter>
<value>
in<parameter_list>
and<params>
in<expression_parameters>
<element>
in<expression_parameters>
Single-type
<instance_replacement>
Complex-type
<instance_replacement>
4.1.5.3. 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. See Table 4.2.
Note
These renamed tags affect only XML-Based Application creation and QoS profiles, not Infrastructure Services schemas. See Section 4.2.7.2 if you are using Routing Service.
Pre-6.1.0 tag |
6.1.0 tag |
---|---|
|
|
|
|
|
|
|
|
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).
4.1.5.5. 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 Micro. The issue affects only MAG because the <instance_replacement>
tag was added in 6.0.1 for MAG, but it is new in 6.1.0 for the Connext
Core Libraries.
(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
in 6.1.0:
<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>