5.3. What’s New in 7.5.0

This section describes what’s new in the Core Libraries compared to release 7.4.0 (see Previous Releases).

RTI® Connext® 7.5.0 is an early access release. See the Connext Versions and Lifecycle page for more information on RTI’s software release model.

For what’s new and fixed in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation. Or start with the RTI Connext What’s New for a launchpad to all products.

Note

For backward compatibility information between 7.5.0 and previous releases, see the Migration Guide on the RTI Community Portal.

5.3.1. Python RPC API now fully productized and supported

This release promotes the Python RPC API from experimental to production-ready. It includes several improvements to the RPC and Request-Reply Python APIs that align the API with the future update of the OMG DDS-RPC standard and provide several new features, most notably an enhanced service discovery protocol.

The Python RPC and Request-Reply improvements in this release follow the improvements for Modern C++ in 7.4.0 and bring the RPC/Request-reply APIs in these two languages up to par.

The enhanced service discovery protocol allows a Client (or a Requester) to reliably discover a Service (or a Replier) before making a call:

  • Clients and Requesters can call a new method, wait_for_service(), to ensure that a service has been discovered.

  • Clients and Requesters will fail immediately when making a request if no service has been discovered. This behavior can be disabled on the Client or Requester with the new argument require_matching_service_on_send_request on the Client and Requester constructor, for interoperability with request-reply APIs in other languages except Modern C++ and previous versions of the Python API.

  • A Service or a Replier will only pass requests to the application layer when it can ensure that the reply can be delivered. This solves a previous race condition that could cause some initial replies for a Client or Requester to be lost.

Other changes include:

  • Python code generation of interfaces is now supported by rtiddsgen, together with example generation when an IDL contains an interface and you use -example universal.

  • The translation of service interfaces has changed to topic-types to align with a future update of the OMG RPC-DDS standard.

  • Allows for the mutability of RPC operations by supporting the @final and @mutable annotations on a per-operation basis.

    For example, the following interfaces are compatible. A Foo client can call my_method on a Bar service, and the other way around (as long as they use the same service name):

    @service("DDS")
interface Foo {
      @mutable
      long my_methodop(in short s, out double d);
};

@service("DDS")
interface Bar {
      @mutable
      void my_method(in short s, out double d, in long l);
};

  • Allows the propagation of built-in exceptions rti.rpc.RemoteUnsupportedOperationError, rti.rpc.RemoteInvalidArgumentError, rti.rpc.RemoteOutOfResourcesError, rti.rpc.RemoteUnknownOperationError, and rti.rpc.RemoteUnknownExceptionError, in addition to the already-supported user-defined exceptions. These built-in exceptions can be explicitly thrown by the service implementation. Additionally, rti.rpc.RemoteUnknownOperationError and rti.rpc.RemoteUnknownExceptionError are reported when the client calls an unknown operation in the service or the service implementation throws an unknown exception, respectively.

  • Allows setting wire compatibility with rti.connextdds.compliance.RpcMask so that the PID_RELATED_SAMPLE_IDENTITY RTPS parameter is set to its standard value. By default, it continues to be set to a non-standard value for backward compatibility with previous Connext versions.

  • Previously the Python API only allowed “in” parameters; support for “out” and “inout” parameters have been added allowing the modification of these parameters in the service side and propagating these changes to the actual parameters where the client invokes the operation.

  • Added support for operation parameters of bounded string type.

  • Added support for operation parameters of sequence type.

  • Added support for @default, @min, and @max annotations on operation parameters.

  • Added support for operation extensibility.

  • Improved internal error management in the server. The server will notify the customer in case of an exception sending the response.

See Request-Reply Exchanges and Remote Procedure Calls (RPC) in the RTI Connext Core Libraries User’s Manual for information on these APIs. Also see the remote_procedure_call and request_reply GitHub examples.

5.3.2. More efficient endpoint discovery for RPC and Request-Reply

This release provides faster discovery for RPC and Request-Reply entities. The Requester.wait_for_service() (for request-reply) or Client.wait_for_service() (for RPC) previously returned TRUE once the DataWriter and DataReader had both matched with a Replier (for request/reply) or Service (for RPC). However, this did not indicate that the external Replier or Service had also discovered the DataWriter and DataReader. This resulted in a need to send additional retries.

Now, wait_for_service() will not return TRUE until both the DataWriter and DataReader have matched and the DataReader has received a heartbeat from the Replier's or Service's DataWriter. This indicates that the remote DataWriter has completed endpoint discovery and is ready to write data. This should reduce the number of retries needed to send a request and have it be received.

This change is an improvement upon the Modern C++ API and is already included in the Python API as part of the new feature Python RPC API now fully productized and supported.

See Request-Reply Endpoint Discovery for more information on endpoint discovery for RPC and Request-Reply.

5.3.3. Improved DataWriter queue sample memory management eliminates required configuration for unbounded types

The way that DataWriters manage the memory that they use to store serialized samples has been improved to prioritize using pre-allocated memory. This enhancement eliminates the need to configure properties out-of-the-box for DataWriters that are using unbounded types.

Previously, DataWriters always tried to allocate buffers to the maximum serialized sample size of a type. For unbounded types, or even types with very large maximum serialized sample sizes, DataWriter creation would fail or consume large amounts of unused memory. To avoid this, the property dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size had to be set to a threshold value. Samples with serialized sizes below this value were stored in pre-allocated buffers and samples with serialized sizes above this value were stored in dynamically allocated buffers.

Now, DataWriters allocate buffers that are more closely sized to the sample sizes that are being written and keeps these buffers around so that they can be reused for subsequent samples that are similarly sized. This avoids dynamic memory allocation, which can hurt the performance and determinism of your application. No configuration is required to send large samples out-of-the-box.

As part of this work, the dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size property has been removed for all use cases except unbounded key members in Java. Setting it will have no effect, and a warning will be printed when a DataWriter that is using this property is created or has its QoS updated.

See Sample Memory Management for DataWriters in the RTI Connext Core Libraries User’s Manual for a detailed explanation of how DataWriters manage the memory for serialized samples.

5.3.4. Enhanced out-of-the-box network performance with updated socket buffer sizes

Several improvements were made to enhance network performance by increasing the default socket buffer sizes and improving the usability of the socket buffer size configuration. These changes provide a better out-of-the-box experience while offering more flexibility in tuning the system for optimal performance.

As part of this update, this release has increased the default UDP socket buffer size from 131072 bytes to 2097152 bytes. This significant adjustment allows for more efficient data transmission and improved network throughput, addressing the demands of high-performance applications. To take full advantage of this updated default, you should adjust the kernel settings to match this new default value. See https://community.rti.com/kb/achieving-low-jitter-performance-connext-pro#Socket-buffer-sizes for details on how to do that.

In cases where the specified send or receive socket buffer size exceeds the maximum value allowed by the system, Connext will now automatically use the maximum value permitted by the system. A warning message (previously printed at local verbosity) is printed in such scenarios, providing suggestions to help you optimize your configuration and better understand system-level limitations.

To further improve usability, this release introduces new configuration options: NDDS_TRANSPORT_UDPV4_SOCKET_BUFFER_SIZE_OS_MAX (-2) and NDDS_TRANSPORT_UDPV6_SOCKET_BUFFER_SIZE_OS_MAX (-2). These options allow you to configure Connext to use the maximum socket buffer size allowed by the operating system. If the system does not define a maximum buffer size, Connext will fail and provide an error message indicating the issue. The previously available configuration constants, NDDS_TRANSPORT_UDPV4_SOCKET_BUFFER_SIZE_OS_DEFAULT (-1) and NDDS_TRANSPORT_UDPV6_SOCKET_BUFFER_SIZE_OS_DEFAULT (-1), remain unchanged and continue to allow the use of the OS default socket buffer size.

These enhancements provide greater flexibility and improve the usability of socket buffer size configuration while improving out-of-the-box network performance. By aligning Connext configuration with system-level constraints, these updates enable smoother operation and better overall efficiency.

For more information, see send_socket_buffer_size and recv_socket_buffer_size in Setting Builtin Transport Properties with the PropertyQosPolicy and Setting Real-Time WAN Transport Properties in the RTI Connext Core Libraries User’s Manual.

5.3.5. Improved scalability for applications using writer-side content filtering

This release enhances the scalability of Connext applications by resolving issues related to writer-side content filtering. Previously, when two DataWriters within the same DomainParticipant performed writer-side filtering, they could interfere with each other, even if they were associated with different Topics and Publishers. Now, DataWriters in separate Topics and Publishers can perform writer-side filtering independently, without interference. This update significantly boosts concurrency, especially in multi-core systems.

5.3.6. Initial discovery performance improvements in large systems with participants containing many endpoints

This release has introduced performance improvements in large systems with DomainParticipants containing many endpoints by reducing the CPU required to match a remote endpoint (DataReader and DataWriter) to a local endpoint.

5.3.7. Eliminated requirement to manually clean up thread resources on platforms that support automatic thread-specific storage (TSS) cleanup

Whenever a Connext API is called by a user thread, some resources are stored in thread-specific storage. In previous Connext releases, the only way to clean up these resources was to called the DomainParticipantFactory::unregister_thread API (ThreadContext::Dispose() in the C# API) before a user-created thread exited.

This release adds support for automatic TSS cleanup on platforms that allow it. On platforms that support automatic TSS cleanup, it is no longer required to call the DomainParticipantFactory::unregister_thread API before a thread exits, although it is safe to do so.

Refer to the Platform Notes to see if your platform supports automatic TSS cleanup. (It will be mentioned in the “Thread Configuration” sub-section of the platform you are using.)

5.3.8. Improved flow control of fragmented sample repairs

When a DataWriter sends two fragmented samples (that is, their serialized size exceeds the configured message_size_max for the transport), and all fragments of the first sample are missed while only a few fragments of the second sample are missed, the DataReader will issue a NACK for the first sample and a NACK_FRAG for the second sample.

In such a scenario, the handling of fragmented sample repairs has been improved to ensure that the max_bytes_per_nack_response limit applies collectively to both NACK and NACK_FRAG repairs. Previously, this limit applied separately to NACKs and NACK_FRAGs, effectively doubling the configured max_bytes_per_nack_response limit. This enhancement ensures that when repairs are delayed using min_nack_response_delay and max_nack_response_delay, the limit is applied to all queued event repairs collectively. This allows for more efficient resource management and makes it easier to specify the maximum allowed size of a repair response.

Note: If repairs are not delayed, the limit still applies separately.

See DATA_WRITER_PROTOCOL QosPolicy (DDS Extension) in the RTI Connext Core Libraries User’s Manual for more information.

5.3.9. RTPS messages containing a malformed inline Qos now trigger a warning, to avoid deserialization errors downstream

To improve the debuggability of Connext applications, this release introduces improvements to the RTPS Inline Qos parsing. Specifically, Connext can now detect the presence of an Inline Qos field that is located too early in the RTPS message. When this situation is detected, Connext logs a warning similar to the following one:

"COMMEND(Anon/Be/Sr)ReaderService_onSubmessage:skip error: protocol parameters"

This improvement avoids cryptic deserialization errors (for example, but not limited to, a generic available space error) getting logged downstream.

5.3.10. Capture periodic DomainParticipant announcements in DISCOVERY logging category to enhance debugging of discovery

The DISCOVERY logging category has been enhanced to include periodic DomainParticipant announcements. This enhancement allows you to track the ongoing presence of discovered DomainParticipants, providing additional insights for debugging unexpected discovery behaviors. Previously, only the initial and final announcements were logged, while periodic announcements were not captured. With this enhancement, periodic announcements are now logged as they are sent.

5.3.12. Updated default value for socket_monitoring_kind to more performant WINDOWS_IOCP value on Windows systems

The default value for the socket_monitoring_kind property has been updated to WINDOWS_IOCP on Windows systems. This value was always recommended for better performance and scalability; now it is the default setting. See TCP/TLS Transport Properties in the RTI Connext Core Libraries User’s Manual.

5.3.13. Support for new metadata fields in content filter expressions

This release introduces support for the following new metadata fields in content filter expressions in the SQL filter:

  • sample_identity.writer_guid.value

  • sample_identity.sequence_number.low

  • sample_identity.sequence_number.high

  • source_guid.value

For example:

@sample_identity.writer_guid.value = &hex(0708090A0B0C0D0E0F10111213141516)

See SQL Filter Expression Notation in the RTI Connext Core Libraries User’s Manual.

5.3.14. InstanceHandle now provides a default constructor

The type dds::core::InstanceHandle was previously expected to be initialized with the special value dds::core::InstanceHandle::nil() or with another InstanceHandle. This caused unnecessary complexity, especially in the initialization of collections of InstanceHandles.

This release adds a default constructor that initializes an InstanceHandle to nil().

5.3.15. Parameter type change to more convenient/appropriate size_t in pluggable transport’s to_string APIs

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.

5.3.16. Deprecations and Removals

This section describes items that are deprecated or removed in 7.5.0, compared to 7.4.0.

Deprecated means that the item is still supported in this release, but will be removed in a future release. Removed means that the item is discontinued or no longer supported.

Any deprecations or removals noted in RTI’s documentation serve as notice under the Real-Time Innovations, Inc., Maintenance Policy #4220 and/or any other agreements by and between RTI and customer regarding maintenance and support of RTI’s software. RTI’s current standard terms and support and maintenance policies are available at https://www.rti.com/terms.

5.3.16.1. “delete” method of DynamicDataTypeSupport deprecated

As a result of the fix for CORE-14359 (see Memory Leaks/Growth), the delete method of the DynamicDataTypeSupport class in the Java API has been deprecated. While its use won’t trigger a compiler error, it will trigger a Deprecation warning and not do anything.

5.3.16.2. dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size removed (except for Java)

As part of the new feature that eliminates required configuration for unbounded types, the dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size property has been removed for all use cases except unbounded key members in Java. Setting the property will have no effect, and a warning will be printed when a DataWriter that is using this property is created or has its QoS updated.

The use of this property by Java is deprecated in this release and will be replaced by automatic behavior in an upcoming release.

5.3.17. Third-Party Software Changes

The following third-party software used by Connext has been upgraded:

Table 5.3 Third-Party Software Upgrades

Third-Party Software

Old Version

New Version

Expat

2.6.2

2.6.3

LZ4

1.9.3

1.9.4

For information on third-party software used by Connext products, see the “3rdPartySoftware” documents in your installation: <NDDSHOME>/doc/manuals/connext_dds_professional/release_notes_3rdparty.