2.1. General Compatibility 760 to 7.7.0

This section describes compatibility issues that affect an upgrade from 7.6.0 to 7.7.0. It describes general, wire, and other compatibility issues between those two releases.

Unless noted otherwise, the issues in this section do not apply to RTI Connext Micro.

See RTI Connext Performance Benchmarks for performance details in this release.

2.1.1. Wire Compatibility

2.1.1.1. RTPS Header Extension timestamp clock has changed

The RTPS Header Extension timestamp used to be populated using an internal clock set by dds.clock.internal_clock. This could lead to the timestamp being populated with an invalid value (from the perspective of the remote host), if the internal clock was set to “monotonic”. Starting in this release, the clock used to generate the RTPS Header Extension timestamp has changed to the external clock, dds.clock.external_clock.

Your application could be affected by this fix if you use the RTPS Header Extension timestamp and rely on its value to be “monotonic”. If you do, consider setting the dds.clock.external_clock property to “monotonic”. Keep in mind that this change would also affect the external clock used in other places. See Configuring the Clock per DomainParticipant for details.

Note that this change does not affect the RTPS Timestamp submessage, which already used and continues to use the external clock.

2.1.2. Type System Compatibility

2.1.2.1. Assignability of 8-bit Types

Previously, int8, uint8, and octet were considered assignable out-of- the-box. In this release, int8, uint8, and octet are treated as distinct types and are no longer considered assignable to one another out-of- the-box. If a DataWriter uses int8 and a DataReader uses octet, they will fail to match, resulting in an INCONSISTENT_TOPIC status.

To get the old behavior back, you must enable TypeObject v1 propagation (the previous default) instead of TypeObject v2 (the new default). You can do this by setting the DomainParticipantResourceLimitsQosPolicy::type_object_max_serialized_length to a value large enough for your types and removing the TYPE_LOOKUP_SERVICE_CHANNEL from the DiscoveryConfigQosPolicy::enabled_builtin_endpoints mask.

<domain_participant_qos>
    <resource_limits>
        <type_object_max_serialized_length>8192</type_object_max_serialized_length>
    </resource_limits>
    <discovery_config>
        <enabled_builtin_channels>SERVICE_REQUEST_CHANNEL</enabled_builtin_channels>
    </discovery_config>
</domain_participant_qos>

If a participant receives TypeObject v1 types from an old application, it will apply the old assignability rules (that is, all 8-bit types will be considered assignable), even if the local participant itself has enabled TypeObject v2.

For more information, see:

2.1.2.2. Recursive Type Support

While the TypeObject v2 specification [1] includes the structural framework to represent recursive types—types that contain members of their own type—Connext does not support recursive types out-of-the-box in this release.

If your system currently relies on recursive types, you must use TypeObject v1. You can do this by setting the DomainParticipantResourceLimitsQosPolicy::type_object_max_serialized_length in your Connext 7.7.0 application to a value large enough for your types and removing the TYPE_LOOKUP_SERVICE_CHANNEL from the DiscoveryConfigQosPolicy::enabled_builtin_endpoints mask.

<domain_participant_qos>
    <resource_limits>
        <type_object_max_serialized_length>8192</type_object_max_serialized_length>
    </resource_limits>
    <discovery_config>
        <enabled_builtin_channels>SERVICE_REQUEST_CHANNEL</enabled_builtin_channels>
    </discovery_config>
</domain_participant_qos>

2.1.2.3. TypeObject v1 no longer propagated by default

To optimize network performance, Connext no longer sends the TypeObject v1 representation by default. Connext can, however, receive TypeObject v1 by default. This is a significant shift for systems involving older Connext applications or those using DynamicData. Because older versions only understand TypeObject v1, they will not receive type definitions from newer applications, which effectively disables their ability to perform assignability checking. The older applications will match with the new applications based on type name only, and if the types are not assignable there is a risk for deserialization errors in the old application. Similarly, older DynamicData applications will lack the type information necessary to function.

To restore the previous behavior for backward compatibility, you must enable sending TypeObject v1 in your 7.7.0 application. You can do this by setting the DomainParticipantResourceLimitsQosPolicy::type_object_max_serialized_length to a value large enough for your types and removing the TYPE_LOOKUP_SERVICE_CHANNEL from the DiscoveryConfigQosPolicy::enabled_builtin_endpoints mask.

<domain_participant_qos>
    <resource_limits>
        <type_object_max_serialized_length>8192</type_object_max_serialized_length>
    </resource_limits>
    <discovery_config>
        <enabled_builtin_channels>SERVICE_REQUEST_CHANNEL</enabled_builtin_channels>
    </discovery_config>
</domain_participant_qos>

Alternatively, you can keep the TYPE_LOOKUP_SERVICE_CHANNEL enabled while also enabling TypeObject v1 propagation. This configuration allows your application to be backwards compatible with Connext versions prior to 7.7.0 and maintains the ability to respond to and make TypeLookup Service requests from systems that do not support TypeObject v1, such as those from other DDS vendors or your own applications where TypeObject v1 propagation is disabled.

To propagate TypeObject v1 and TypeObject v2:

  • Change type_object_max_serialized_length from 0 to the desired length.

  • Set the DiscoveryConfigQosPolicy::enabled_builtin_channels mask to include the TYPE_LOOKUP_SERVICE_CHANNEL.

See Type Representation in the RTI Connext Core Libraries Extensible Types Guide for more information.

Applications that enable both TypeObject v1 and the TYPE_LOOKUP_SERVICE_CHANNEL will not fully benefit from performance and feature improvements that come with the addition of TypeObject v2 and the TypeLookup Service; however, enabling both provides a path towards full adoption of TypeObject v2 as your system migrates Connext versions.

2.1.2.4. Multiple Calls to Builtin Listeners

The introduction of the TypeLookup Service means that type resolution is now an asynchronous process. Consequently, the builtin PublicationBuiltinTopicData and SubscriptionBuiltinTopicData listeners on_data_available may be triggered multiple times for the same endpoint. The first call occurs when the endpoint is discovered but before the type definition has been retrieved; in this instance, the type_code will be NULL. A second call will occur once the type is successfully resolved. Any application logic that inspects discovered types must be updated to check for a non-NULL type_code before attempting to access it, to prevent runtime crashes.

2.1.2.5. Requirement for request_types_filter

Applications that need to discover types at runtime, such as those using DynamicData, must now take an active role in the discovery process. This is because Connext does not request types for endpoints for which it does not have a local endpoint match. This means that if a remote endpoint is discovered with a type hash that the local participant does not recognize, it will only request the type if there is a local endpoint for the same Topic as the remote endpoint and the QoS of the two endpoints otherwise match. That is, if they are on different partitions or have some other QoS incompatibility, the type will not be requested.

If your application requires discovering all types, either because you are using the discovered types to create DynamicData endpoints or using them for some other purpose, you can configure the DiscoveryConfigQosPolicy::request_types_filter. (See DISCOVERY_CONFIG QosPolicy (DDS Extension) in the RTI Connext Core Libraries User’s Manual.) The request_types_filter is a regular expression telling the participant which Topics it should unconditionally request the unknown types for. For example, if you want to request all unknown types, you can set it to *, and if you want to request types only for Topic “Foo”, you can set it to Foo.

Connext Infrastructure Services and Tools that rely on discovering types set this QoS to * by default. This could mean that they request more types than are necessary in your system. For example, in Routing Service, if you are only routing a subset of Topics, you may want to set request_types_filter to only request types for the Topics that you plan on routing.

Footnotes