2.2.1. RTI Connext Core Libraries
The following issues affect backward compatibility in the Core Libraries starting in release 7.4.0. Issues in the Core Libraries may affect components that use these libraries, including Infrastructure Services and Tools.
2.2.1.1. 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.
2.2.1.2. 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 2.2.1.1) 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.
2.2.1.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.
2.2.1.4. New discovery protocol APIs for RPC and Request-Reply in Modern C++
2.2.1.4.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++ API 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” in What’s New in 7.4.0 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++ 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.
2.2.1.4.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.