3.2.1. RTI Connext Core Libraries

The following issues affect backward compatibility in the Core Libraries when migrating to release 7.7.0. Issues in the Core Libraries may affect components that use these libraries, including Infrastructure Services and Tools.

3.2.1.1. API Compatibility

3.2.1.1.1. Sample assignability default value changed in from_cdr_buffer APIs

In previous releases, it was not possible to configure how the from_cdr_buffer APIs handle a serialized sample with a union discriminator that does not select a union member or an enum value unknown to the type. Previously, the behavior was to set default union and enum values when deserializing the sample. This was the same as setting the following properties (now deprecated; see Section 3.2.1.2.2) to 1: dds.sample_assignability.accept_unknown_union_discriminator and dds.sample_assignability.accept_unknown_enum_value.

This behavior is now configurable. The default behavior now is to fail to deserialize a sample under the above conditions. To configure how the from_cdr_buffer APIs handle a serialized sample with a union discriminator that does not select a union member or an enum value unknown to the type, you can set the following bits in the Extensible Types compliance mask:

• accept_unknown_enum_value(): 0x00000010

• accept_unknown_discriminator(): 0x00000020

• select_default_discriminator(): 0x00000040

To revert to the default behavior of previous releases, enable the previous three bits by setting the mask to 0x00000070.

For more information, see Extensible Types Compliance Mask in the RTI Connext Core Libraries Extensible Types Guide.

3.2.1.1.2. Multiple attachments/detachments of same condition to WaitSet no longer allowed

The behavior of attaching a condition to a WaitSet has been updated to prevent multiple attachments of the same condition.

Previously, if the same condition was attached to a WaitSet multiple times, each attachment was accepted. As a result, the condition had to be detached the same number of times it was attached to be fully removed from the WaitSet.

Now, if the same condition is attached more than once, only the first attachment has an effect. Subsequent attachments are ignored. The condition is considered attached only once, and therefore only needs to be detached once to be fully removed.

If your application logic previously attached the same condition multiple times and detached it accordingly, you should update it to:

• Attach each condition only once.

• Detach each condition only once, regardless of how many times it was previously attached.

This change simplifies usage and ensures consistent behavior in the WaitSet.

3.2.1.1.3. New discovery protocol APIs for RPC and Request-Reply in Modern C++ and Python

3.2.1.1.3.1. Discovery

In previous releases, the discovery process in RPC and Request-Reply was not reliable, sometimes causing loss of replies to the first requests. This release introduces an enhanced discovery protocol in the Modern C++ and Python APIs between clients and services that guarantees that the client and the service are ready to communicate in both directions. (See Modern C++ RPC API now fully productized and supported and Python RPC API now fully productized and supported in the RTI Connext Core Libraries Release Notes for more information.)

Therefore, starting in this release, sending the first request with a Requester requires ensuring that discovery has finished with the wait_for_service method. If discovery hasn’t finished, the send_request method will immediately fail. This new discovery protocol is not interoperable with previous releases or with Repliers built in the C, Traditional C++, Java, and C# APIs. When communicating with a Replier built with a previous release or one of these languages, the wait_for_service operation will time out, and send_request may fail. If you need to interoperate with a previous release or one of these languages, create the Requester with the parameter require_matching_service_on_send_request set to false and avoid calling wait_for_service.

The same changes are required to use the Modern C++ or Python RPC API: before making the first remote function call with a Client, ensure that discovery has finished with wait_for_service. Previous releases of the RPC API were experimental, and this release won’t interoperate with them.

3.2.1.1.3.2. Wire interoperability

Connext does not use the standard value for PID_RELATED_SAMPLE_IDENTITY defined in the OMG DDS RPC specification. The PID_RELATED_SAMPLE_IDENTITY is included in the inlineQoS sub-message and is used to correlate samples sent as reply to a request.

In this release, RPC and Request-Reply keep the previous (non-standard) value for backwards compatibility between releases; however, Connext will not interoperate with other vendors by default.

To use the standard PID_RELATED_SAMPLE_IDENTITY value and interoperate with other vendors, set PID_RELATED_SAMPLE_IDENTITY at the application level using the environment variable NDDS_RPC_COMPLIANCE_MASK, or at the DataWriter or DomainParticipant level using the property dds.rpc.compliance_mask. See Standard Compliance in the RTI Connext Core Libraries User’s Manual for instructions. Using the standard value will prevent communication with older versions of Connext.

3.2.1.1.4. Changed C function signatures could cause signed/unsigned warnings when compiling application code

The type of the buffer_size_in parameter has been updated from RTI_INT32 to size_t in the following pluggable transport C APIs:

• NDDS_Transport_Address_to_string

• NDDS_Transport_Address_to_string_with_class_id

• NDDS_Transport_Address_to_string_with_protocol_family_format

For example, see NDDS_Transport_Address_to_string().

The behavior of the APIs has not changed, since the buffer_size_in parameter represents the size of the buffer used to get the address as a string, which should be positive. However, people using these functions could find benign warnings as a result of this change.

3.2.1.2. Configuration Changes

3.2.1.2.1. max_samples_per_instance needs to be consistent with max_samples for unkeyed types

Release 7.6.0 fixed an issue (CORE-5643) with enforcing consistency between DDS_ResourceLimitsQosPolicy::max_samples_per_instance and DDS_ResourceLimitsQosPolicy::max_samples for unkeyed types. If you were setting max_samples_per_instance to a smaller value than max_samples for an unkeyed type, then Topic, DataWriter, or DataReader creation incorrectly succeeded. Now entity creation correctly fails if the values do not match, with an error message like this one:

ERROR DDS_ResourceLimitsQosPolicy_is_consistentI:INCONSISTENT QOS | For an unkeyed type, max_samples_per_instance (4) must equal max_samples (6) or DDS_LENGTH_UNLIMITED.

As the error message indicates, you need to change the value of max_samples_per_instance to either the value of max_samples or DDS_LENGTH_UNLIMITED.

3.2.1.2.2. Properties dds.sample_assignability.accept_unknown_enum_value and dds.sample_assignability.accept_unknown_union_discriminator have been deprecated

The properties dds.sample_assignability.accept_unknown_enum_value and dds.sample_assignability.accept_unknown_union_discriminator have been deprecated and may be removed in a future release. If you are using them, you can continue using them; however, it is strongly recommended that you configure their behavior instead through the Extensible Types compliance mask, which configures different aspects of the Extended CDR encoding (XCDR and XCDR2):

• Enabling what was previously set by dds.sample_assignability.accept_unknown_enum_value is now configured by setting the following bit: accept_unknown_enum_value(): 0x00000010.

• Configuring what was previously set by dds.sample_assignability.accept_unknown_union_discriminator depends on the value you were assigning to it:

  Note

  In this context, “unknown discriminator” means a discriminator value that does not select a union member on the DataReader side.

  • 0 - Reject samples with an unknown discriminator: you don’t need to set any bits.

  • 1 - Accept samples with an unknown discriminator and assign the default discriminator value: set the following bits:

    • accept_unknown_discriminator(): 0x00000020 to accept the sample.

    • select_default_discriminator(): 0x00000040 to select the default discriminator value.

    If select_default_discriminator() is left unset and accept_unknown_discriminator() is set, then the sample will be accepted, and the unknown union discriminator value will be preserved.

  • 2 - Accept samples with an unknown discriminator: set the following bit: accept_unknown_discriminator(): 0x00000020.

For more information, see Extensible Types Compliance Mask in the RTI Connext Core Libraries Extensible Types Guide.

3.2.1.2.3. Can no longer use “DDS_” prefix with KEEP_LAST_HISTORY_QOS and KEEP_ALL_HISTORY_QOS enumeration values in XML files

Before this release, the DDS-prefixed enumerations DDS_KEEP_LAST_HISTORY_QOS and DDS_KEEP_ALL_HISTORY_QOS were valid in the XSD files, as well as the standard enumerations, KEEP_LAST_HISTORY_QOS and KEEP_ALL_HISTORY_QOS. Having both sets of enumerations (with and without the “DDS_” prefix) in the XSD files was confusing. In this release, RTI has updated the XSD files by removing the non-standard enumerations DDS_KEEP_LAST_HISTORY_QOS and DDS_KEEP_ALL_HISTORY_QOS and keeping the standard ones, KEEP_LAST_HISTORY_QOS and KEEP_ALL_HISTORY_QOS.

The primary goal of this change is to ensure that tools utilizing XSD files are aligned with standard DDS enumerations, thereby reducing potential confusion and maintaining consistency across applications. It’s important to note that while these DDS-prefixed enumerations have been removed from the XSD files, they remain valid within the Connext XML parser. This means that existing configurations using these terms will continue to operate as expected.

However, anyone leveraging third-party tools for XML file validation might encounter warnings or errors if the removed DDS-prefixed enumerations are still in use. These tools may no longer recognize these enumerations as valid due to the enumerations’ absence in the updated XSD files. We recommend reviewing and updating your XML configurations to use the standard enumeration terms to ensure seamless compatibility and validation across all tools and applications.

3.2.1.2.4. Aliases for enabled_transport QoS no longer use case-sensitive matching

The enabled_transport QoS previously required exact case matches for transport aliases. Now, alias matching is case-insensitive.

If you rely on case sensitivity for custom transports in your enabled_transport values, your upgrade to 7.7.0 will no longer distinguish the values by case. For example:

<!-- Distinct custom transports with case-sensitive names -->
<transport_builtin>
    <mask>NONE</mask>
</transport_builtin>
<property>
    <name>dds.transport.load_plugins</name>
    <value>MyPlugin,myplugin</value> <!-- Previously two different plugins, now treated the same -->
</property>

3.2.1.3. Logging Changes

3.2.1.3.1. Changes in RTI Connext logging behavior for Windows desktop applications

By default, Windows® desktop applications (i.e., Windows applications with a graphical user interface) do not have an associated console for displaying Connext log messages logged to the standard output. In previous releases, to avoid losing important messages, Connext automatically created a Windows console and redirected the output to it.

Now, as part of the fix for an issue (CORE-15707), this behavior has changed: Connext no longer creates Windows consoles for logging. The reason for this change is that, by default, attached Windows consoles terminate the associated process when the console is closed, which might affect the usability of the application.

To avoid losing important log messages in Windows desktop applications, install a logger device to capture and display the messages as desired. See Customizing the Handling of Generated Log Messages in the Connext Core Libraries User’s Manual for more information on how to install a logger device.

3.2.1.4. Utilities Changes

3.2.1.4.1. RTI DDS Spy transport option now uses string-based masks instead of integers

Starting in release 7.7.0, the -transport option in RTI DDS Spy has changed from using a bitmask (integer values) to using a more user-friendly mask of string literals separated by |.

In previous releases, you configured the -transport option using integer values representing a bitmask. For example:

rtiddsspy -transport 1     # UDPv4 only
rtiddsspy -transport 2     # Shared memory only
rtiddsspy -transport 3     # UDPv4 and shared memory
rtiddsspy -transport 8     # UDPv6 only
rtiddsspy -transport 9     # UDPv4 and UDPv6
rtiddsspy -transport 10    # Shared memory and UDPv6
rtiddsspy -transport 11    # UDPv4, shared memory, and UDPv6

Starting in 7.7.0, you configure the -transport option using human-readable transport alias names combined with the | separator:

rtiddsspy -transport udpv4               # UDPv4 only
rtiddsspy -transport shmem               # Shared memory only
rtiddsspy -transport "udpv4|shmem"       # UDPv4 and shared memory (default)
rtiddsspy -transport udpv6               # UDPv6 only
rtiddsspy -transport "udpv4|udpv6"       # UDPv4 and UDPv6
rtiddsspy -transport "shmem|udpv6"       # Shared memory and UDPv6
rtiddsspy -transport "udpv4|shmem|udpv6" # UDPv4, shared memory, and UDPv6

The following table shows the mapping between the old integer values and the new string-based aliases:

Previous Format (Bitmask)	New Format (String Aliases)
1	udpv4
2	shmem
3	udpv4|shmem
8	udpv6
9	udpv4|udpv6
10	shmem|udpv6
11	udpv4|shmem|udpv6

If you have scripts that use the old integer-based format, you will need to update them to use the new string-based format.

3.2.1.5. Library Size

The size of the Core Libraries has changed significantly in release 7.7.0 due to a compiler version update and the addition of new features and compiler optimizations. In general, the library sizes have decreased, with only a small number of libraries showing an increase. The following table compares the sizes of the most important libraries for releases 7.3.1 and 7.7.0 on Linux platforms. The size of the libraries may vary on other platforms.

Table 3.1 Library Size Comparison for x64Linux4gcc7.3.0/x64Linux4gcc8.5.0 in MBs

	7.3.1	7.7.0	Change (%)
libnddscpp.so	1.72	1.57	-8.2
libnddscpp2.so	1.35	1.12	-17
libnddsc.so	7.09	7.07	-0.33
libnddscore.so	8.51	9.53	+11.98
librtiroutingservice.so	5.8	3.4	-40.64
librtimonitoring2.so	6.14	5.62	-8.5

3.2.1.6. Memory Consumption

In general, release 7.7.0 applications consume less heap memory than 7.3.1 applications. Stack size is similar between the two releases; there are no significant changes in the stack size.

The following table shows the heap memory differences:

Table 3.2 Heap Memory Differences

Entity	7.3.1	7.7.0	Change (%)
Participant	2021826	1844482	-8.77
Type	1581	1528	-3.35
Topic	2390	2619	9.58
Subscriber	9584	6015	-37.24
Publisher	3808	3639	-4.44
DataReader	74608	28712	-61.52
DataWriter	44900	32824	-26.90
Instances	646	662	2.48
Sample	1401	1391	-0.71
Remote DataReader	7826	7094	-9.35
Remote DataWriter	16107	8716	-45.89