2.2.1. RTI Connext Core Libraries

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

2.2.1.1. Incompatibility between Python API and other APIs when using int8 type

Release 7.5.0 fixed an issue (PY-190) with communication between Python and the rest of the language APIs when using an int8 type. The int8 types were incorrectly treated as characters instead of octets, leading to communication failures.

This fix included changing the type to an octet, which means that the set_int8 methods that accepted a char as an argument have been removed. As a result, communication will not occur between Python 7.3.0 or 7.4.0 applications and Python applications in other releases (such as 7.5.0) that have the fix, when using an int8 type.

Since int8 types are well interpreted by Python, a workaround is to not propagate the TypeObject and rely on the topic name for matching:

<domain_participant_qos>
    <resource_limits>
        <type_object_max_serialized_length>0</type_object_max_serialized_length>
    </resource_limits>
</domain_participant_qos>

If the application you’re communicating with uses a version of Connext earlier than 6.0.0, the TypeCode also needs to be configured to not be propagated:

<domain_participant_qos>
    <resource_limits>
        <type_code_max_serialized_length>0</type_code_max_serialized_length>
        <type_object_max_serialized_length>0</type_object_max_serialized_length>
    </resource_limits>
</domain_participant_qos>

See DOMAIN_PARTICIPANT_RESOURCE_LIMITS QosPolicy (DDS Extension) in the Connext Core Libraries User’s Manual for more information on the type_code_max_serialized_length and type_object_max_serialized_length fields. See Type Representation in the Connext Core Libraries Extensible Types Guide for more information on TypeCode and TypeObjects in current and previous releases.

2.2.1.2. New discovery protocol APIs for RPC and Request-Reply in Python

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

This release fully implements the discovery protocol in the Python API, bringing the Modern C++ and Python RPC and Request-Reply APIs up to par. See Python RPC API now fully productized and supported in the RTI Connext Core Libraries Release Notes for more information.

For Python starting in 7.5.0, sending the first request with a Requester requires ensuring that discovery has finished with the wait_for_service() method. If discovery has not finished, the send_request() method will immediately fail.

This new discovery protocol is not interoperable with Python applications on Connext 7.4 or below. The discovery protocol is not interoperable with any applications on 7.3 or below, nor with any applications built with with the C, Traditional C++, Java, and C# APIs. If a Requester tries to communicate with a Replier built with a previous incompatible release or one of these languages, wait_for_service() 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().

2.2.1.3. 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.