3.4.1. General Compatibility 6.0.0
This section describes compatibility issues that affect the Connext 6 suite. It describes general, wire, and platform compatibility issues between Connext 6 and previous releases.
Unless noted otherwise, the issues in this section do not apply to RTI Connext Micro.
22.214.171.124. Wire Compatibility
126.96.36.199.1. RTPS Versions
For information about the RTPS versions supported for each Connext release, see Compatibility, in the RTI Connext DDS Core Libraries Release Notes (7.1.0).
188.8.131.52.2. New default GUID generation mode
Starting in 6.0.0, the default value of
DDS::DomainParticipantQos::wire_protocol::rtps_auto_id_kind has changed from
DDS_RTPS_AUTO_ID_FROM_IP (which caused the
rtps_host_id to be the IP address by
DDS_RTPS_AUTO_ID_FROM_UUID (which causes the
rtps_instance_id to be a
unique, randomly generated value). This change was done to comply with the latest
RTPS specification and reduce the possibility of non-unique GUIDs due to process
As a result of this change, out-of-the-box, DomainParticipants within the same process no longer
have a GUID that is ordered by creation time (via
rtps_instance_id). In other
words, you can no longer expect that all DomainParticipants will be ordered
sequentially within an application, since they are now using a random value to
determine the GUID rather than a sequential (time-based) value. This new ordering
may affect the usage of API functions that output a list of DomainParticipant
InstanceHandles, such as
Furthermore, if you are using older versions of RTI Administration Console and RTI Monitor to display data from a Connext 6 application, these tools may display confusing information if system properties (those that start with “dds.sys_info”) are turned off. When you turn off system properties during discovery (to save on bandwidth and discovery time), older versions of Admin Console and Monitor figure out what those properties are by assuming that part of the GUID is the host IP address and process ID. (In some cases, Admin Console and Monitor can find the IP address through the locators, but if that information is not available, the tools will also assume that the random value is the IP address.) For more information on how your older version of Admin Console or Monitor handles host name and process ID, see the Help menu in Admin Console for your specific version or see the RTI Monitor User’s Manual for your specific version. (All older versions of Admin Console will have this issue with Connext 6 data, out-of-the-box; not all older versions of Monitor will have this issue out-of-the-box.)
If you want the default value to be
DDS_RTPS_AUTO_ID_FROM_IP instead of
DDS_RTPS_AUTO_ID_FROM_UUID, like it was before, change it in the
WIRE_PROTOCOL QosPolicy. (Remember that the old default value increases
the possibility of non-unique GUIDs due to process ID collision.)
184.108.40.206.4. 4.2e alignment option deprecated
If your Connext application’s data type uses a
unsigned long long, or
long double, it will not interoperate with
applications built with RTI Data Distribution Service 4.2e or lower.
In previous releases (5.3.1 or lower), you could use the
command-line option when generating code with RTI Code Generator, in combination
with the properties
dds.data_reader.type_support.use_42e_alignment, to get backward compatibility.
These options are no longer available in Connext 6. The option
DynamicDataTypeSerializationProperty_t is not available either.
If you need interoperability between Connext 6 and 4.2e applications, contact RTI Support at email@example.com.
220.127.116.11.5. Changed wire representation of TypeObject
See information about this change in Section 18.104.22.168.2.
22.214.171.124. Reliability Protocol
126.96.36.199.1. Changes in behavior of write() operation with KEEP_LAST configuration
In previous releases, a race condition may have caused the write operation on a
KEEP_LAST DataWriter to return a timeout error when the send window was full and the
blocking time expired (according to
max_blocking_time in the Reliability QosPolicy).
This race condition occurred only with small blocking times.
A keep-last reliable DataWriter will block if the send window is full,
but it should not return a timeout error. In 6.0.0, this timeout problem has been
fixed (see RTI Issue ID CORE-8845 in the “Other Fixes” section of the
Core Libraries Release Notes for 6.0.0). If the blocking time expires,
the new sample is added to its associated instance. If there are
in the instance, the new sample replaces the oldest sample of the same instance,
even if that sample is not fully acknowledged.
188.8.131.52. Type System Compatibility
184.108.40.206.1. Migration to Extended CDR encoding version 2 (XCDR2)
Starting in 6.0.0, Connext supports the Extended Common Data Representation (CDR) encoding version 2 (XCDR2), in addition to version 1 (XCDR). XCDR2 is supported in both Connext and Connext Micro.
XCDR2 is more efficient on the wire than Extended CDR encoding version 1 (XCDR). For new applications, Extended CDR encoding 2 is the recommended data representation; however, if you need to keep compatibility and interoperability with old Connext applications (5.3.1 and below), you may have to continue using Extended CDR encoding 1.
You may use the new
DataRepresentationQosPolicy in the
configure which version of Extended CDR, version 1 or version 2, the DataWriter will use
to serialize its data. The same QosPolicy exists in the
configure which version(s) the DataReader will accept from DataWriters.
DataWriters can offer only one data representation, while DataReaders can
request multiple data representations. The default value AUTO is translated into
DataReaders can be configured to receive data using both XCDR2 and XCDR. This way, a DataReader can still interoperate and receive data from old Connext DataWriters using XCDR, while receiving data from new DataWriters using XCDR2.
The opposite is not true. DataWriters can publish only one data representation. Therefore, if there is a requirement to receive data for a topic ‘T’ with old Connext DataReaders, you will have to continue to publish data for topic ‘T’ with XCDR representation on the new DataWriters or use a bridge such as RTI Routing Service to translate between XCDR and XCDR2.
For additional information, see the RTI Connext Core Libraries Getting Started Guide Addendum for Extensible Types.
220.127.116.11.2. Changed wire representation of TypeObject
In 6.0.0, Connext enables TypeObject compression by default to reduce bandwidth usage when exchanging endpoint discovery data. Specifically, Connext reduces the size needed to propagate a TypeObject as part of Simple Endpoint Discovery. With this feature, a compressed version of the serialized TypeObject (TypeObjectLb) is now sent as a Simple Endpoint Discovery parameter. See What’s New in 6.0.0 for details.
As a result of this feature:
Previous versions of Connext will not be able to receive TypeObject out-of-the-box from applications running Connext 6, since that TypeObject is now compressed.
Therefore, out-of-the-box, type matching with Connext 5.x applications and lower will be done using the registered type name and not the TypeObject. If the registered type names in the DataWriter and DataReader are different, Connext 6 and higher applications will not communicate with Connext 5.x and lower applications.
When Connext 6 applications detect this scenario, the following warning will be logged:
DISCBuiltinTopicPublicationDataPlugin_deserialize:Received type information for a remote Participant that does not support TypeObject compression. TypeObject compression is currently enabled for the local participant, which may prevent communication between local and remote Participant if registered typenames are different. In order to avoid this issue, please set DiscoveryConfigQosPolicy's endpoint_type_object_lb_serialization_threshold to -1 to disable TypeObject compression.
Additionally, Connext 5.x services and tools relying on type definitions require you to register the type through XML to properly work out-of-the-box with 6.x. For example, if Routing Service 5.x communicates with an out-of-the-box 6.x application, types will not be received through discovery. Therefore, you need to configure the types in the Routing Service configuration file (see the Route Types section in the Routing Service User’s Manual). Otherwise, Routing Service will not be able to create routes.
If your system is affected by any of the above issues, you have a few options:
Don’t send the compressed TypeObject. Set
endpoint_type_object_lb_serialization_thresholdin the Connext 6 application’s
DISCOVERY_CONFIGQosPolicy to -1 for the DomainParticipant. Setting this field to -1 sends the old TypeObject instead of TypeObjectLb. See the DDS_DiscoveryConfigQosPolicy table in the RTI Connext Core Libraries User’s Manual.
If using XML configuration, you can use the following snippet within the
<discovery_config> <endpoint_type_object_lb_serialization_threshold> -1 </endpoint_type_object_lb_serialization_threshold> </discovery_config>
If you experience only the type-matching issue but don’t have old services or tools, make the registered type names equal. For information on how the type matching is done, see the “TypeConsistencyEnforcement QosPolicy” section in the RTI Connext Core Libraries User’s Manual or in the RTI Connext Core Libraries Getting Started Guide Addendum for Extensible Types.
If you experience the type issue only with old services or tools, update the service’s or tool’s configuration file to load the type definition from XML.
18.104.22.168.3. TypeCode information is not sent by default
Starting in 6.0.0, the default value for
type_code_max_serialized_length has changed to 0 (from 2048). This change
disables sending TypeCode by default, in order to decrease Endpoint Discovery
This change may affect compatibility with old Connext (4.5f and below) applications whose functionality depended on discovering the type information from remote applications using TypeCodes. Connext 4.5f and below did not support TypeObjects (the standard alternative to TypeCode) as a way to exchange type information; the only way to do that was through TypeCodes.
This change may also affect compatibility with old versions of RTI Routing Service (4.5f and below) if you did not provide the type definitions to Routing Service using XML. In this case, some routes in the old Routing Service may stop forwarding data.
If you have this problem with Connext 4.5f and below, configure your
Connext 6 application to send TypeCodes by setting
type_code_max_serialized_length to the old default value (2048) or a
bigger value if your types need it.
22.214.171.124.4. Unbounded sequences and strings in XML type representation
Previously, if a type defined in XML had its sequences or strings set to -1
in the attributes
stringMaxLength, the resulting
sequence or string length was interpreted as being of a default bounded
size rather than unbounded. The default size for sequences was 100 and
for strings was 255. This problem has been resolved. The resulting length
is now interpreted as unbounded in Connext 6.
This change may lead to some unexpected memory growth when moving existing applications to Connext 6.
If the strings and/or sequences are not supposed to be unbounded, set the maximum length to 100 for sequences and 255 for strings.
If the strings or sequences are supposed to be unbounded, make sure that
you limit the memory usage by using properties such as
<memory_management> tag in RTI Routing Service, RTI Recording Service,
and XML-Based Application Creation. For additional information, see the
“DDS Sample-Data and Instance-Data Memory Management” chapter in the
RTI Connext Core Libraries User’s Manual.
126.96.36.199.5. wchar and wstring language binding changes
Starting in Connext 6.0.0 (and Connext Micro 3.0.0), for C, traditional C++,
and Ada languages, the mapping of an IDL wchar has changed from a 4-byte
integer to a 2-byte integer.
DDS_Wchar is now mapped to
DDS_UnsignedLong. This change may lead to some compilation warnings
when compiling old Connext applications with libraries in Connext 6
(and Connext Micro 3.0.0) and higher. If so, you will need to fix these
Wire interoperability with Connext 5.x and lower (and Connext Micro 2.4.x and lower) is not broken as long as you continue using the Extended CDR encoding version 1 data representation (see the Data Representation chapter in the RTI Connext Core Libraries Getting Started Guide Addendum for Extensible Types), because the wire representation of a wchar and wstring is still the same.
188.8.131.52. Transport Compatibility
184.108.40.206.1. Default shared memory locator has changed
Connext 6 changes the way Connext detects if two different DomainParticipants can communicate over shared memory. In previous releases, the compatibility detection was based on both DomainParticipants having the same shared memory locator. In this release, the compatibility detection is based on checking if it is possible to attach to a shared memory segment compatible with Connext. See “Improved shared memory transport compatibility detection” in What’s New in 6.0.0 for more information.
As a result of this change, Connext 6 applications will not communicate over shared memory with older Connext applications. You will need to take the following action, depending on what release you’re communicating with.
To communicate over shared memory with Connext 5.3:
WIRE_PROTOCOLQoS: In Connext 5.3 and Connext 6, set the
DDS_RTPS_AUTO_IDin all the DomainParticipants running on the same host. In Connext 6 DomainParticipants, set the
rtps_auto_id_kindfield to the same value used in the Connext 5.3 application. If the Connext 5.3 DomainParticipants are using an
DDS_RTPS_AUTO_ID_FROM_UUID, it is also required to set the
dds.transport.shmem.builtin.use_530_from_uuid_locatorproperty to TRUE for all the Connext 6 DomainParticipants. (By default, it is set to FALSE.)
rtps_host_idfield cannot be set to
DDS_RTPS_AUTO_IDdue to system restrictions, set the
dds.transport.shmem.builtin.host_idproperty to the same value for all the DomainParticipants running on the same host. (That is, each DomainParticipant has to have the property set to the same value.)
To communicate over shared memory with Connext 5.2 or older versions:
WIRE_PROTOCOLQoS: In Connext 5.2 or older versions, set the
DDS_RTPS_AUTO_IDin all the DomainParticipants running on the same host. In Connext 6 DomainParticipants, set the
Another option, available only if the
rtps_host_id(in Connext 5.2 or older) is set to a value different than
DDS_RTPS_AUTO_ID: define the
dds.transport.shmem.builtin.host_idproperty in Connext 6 DomainParticipants with the same value as
WIRE_PROTOCOLQoS of the older version.
220.127.116.11. XML Compatibility
18.104.22.168.1. QoS Profile multiple inheritance
QoS Profile composition (also referred to as QoS Profile multiple inheritance) is an enhancement to the existing QoS Profile single inheritance mechanism, allowing a QoS Profile to be composed from multiple QoS Profiles. See the QoS Profile Inheritance and Composition Guidance article on the RTI Community Portal (or the section “QoS Profile Inheritance and Composition” in the RTI Connext Core Libraries User’s Manual Version 6.0.1 if you are upgrading to 6.0.1 or above) for new recommendations in Connext 6. Following these recommendations is strongly encouraged to avoid unexpected results.
22.214.171.124. Other Compatibility Issues
126.96.36.199.1. Behavior change when retrieving QoS using topic_name (when there are multiple matching QoSes)
When you have multiple matching QoSes of the same type (e.g.,
because either a
topic_filter attribute is not provided or it is
provided with “*”, the new behavior in Connext 6 is for Connext to return the
first matching QoS. Previously, Connext returned the last matching
For example, you could use a Connext API that returns a QoS based on a
topic_name value. In the C API, you could use a function like
to return a QoS based on a topic name.
Consider the following XML snippet:
<qos_profile name="String_Specified"> <datawriter_qos name="A" topic_filter="A1_*"> ... </datawriter_qos> <datawriter_qos name="B" topic_filter="B2_*"> ... </datawriter_qos> <datawriter_qos name="C"> ... </datawriter_qos> <datawriter_qos name="D"> ... </datawriter_qos> <datawriter_qos name="E"> ... </datawriter_qos> </qos_profile>
Say that the above is your XML file, and you specify the
Neither A nor B matches “MyTopic”, so Connext has to choose one of the
other QoSes (C, D, or E). Since C, D, and E have no specified
any of them could be used as a matching candidate for “MyTopic”. Before
6.0.0, the API would have returned the “E” QoS, because E is the last
matching QoS. This behavior has changed. Convention dictates that the first
matching candidate should be used, not the last. Therefore, if there is no
QoS that matches the
topic_name, Connext now gets the first candidate
QoS value with
topic_filter unspecified—in this case, C instead of E.
Now consider the following XML snippet:
<qos_profile name="String_NULL"> <datawriter_qos name="A" topic_filter="A1_*"> ... </datawriter_qos> <datawriter_qos name="B" topic_filter="B2_*"> ... </datawriter_qos> <datawriter_qos name="C" topic_filter="*"> ... </datawriter_qos> <datawriter_qos name="D" topic_filter="*"> ... </datawriter_qos> <datawriter_qos name="E" topic_filter="*"> ... </datawriter_qos> </qos_profile>
Say that the above is your XML file, and you don’t specify a
Connext cannot find a QoS in this file with an unspecified
however, it can match with one of the “*”
topic_filter attributes—but there
are multiple such QoSes. Before 6.0.0, Connext returned the “E” Qos
(the last matching candidate value). Now, in 6.0.0 forward, Connext returns the
first candidate value, C.
As a result of this change in Connext 6, you may see a different QoS returned
than before, but only in cases where there are multiple matching QoSes to
choose from. If you want the same behavior in Connext 6 as before, change the
order of the QoSes in your XML file. For instance, in the above examples,
switch the C
<datawriter_qos> with the E