5.1. What’s New in 7.6.0

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

RTI® Connext® 7.6.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.6.0 and previous releases, see the Migration Guide on the RTI Community Portal.

5.1.1. Updated default heartbeat periods for faster repairs of lost samples

The out-of-the-box default values for the RtpsReliableWriter::heartbeat_period, fast_heartbeat_period, and late_joiner_heartbeat_period for DataWriters have been changed from 3 seconds to 200 milliseconds. The RtpsReliableWriter::max_heartbeat_retries QoS has also been changed from 10 to 150 in order to maintain the same amount of time it takes before a DataReader is considered inactive (30 seconds).

These changes affect only reliable DataWriters. The heartbeat period controls how fast samples can be repaired. Previously, user-created DataWriters sent heartbeats every 3 seconds by default; it therefore took up to 3 seconds before a DataReader requested a repair for a lost sample. The new defaults speed up the repair process. The faster heartbeat periods could mean that you may notice an increase in network traffic because there are more heartbeats and acknowledgments being sent. You may choose to slow down the defaults if your network is not lossy and you can wait longer for samples to be repaired if they are lost.

See DDS_RtpsReliableWriterProtocol_t, in the RTI Connext Core Libraries User’s Manual, for more information.

5.1.2. DNS tracker now enabled by default to reduce chance of discovery problems when using hostnames in peer lists

Connext allows the use of hostnames instead of IP addresses when configuring peers for specific transports (e.g., UDPv4 and UDPv6). The DNS tracker keeps the IP addresses of these hostnames updated after DomainParticipant creation. The DNS tracker does this by creating a thread that regularly polls the DNS service. This thread detects changes in the IP address that a hostname is resolved to and updates the related peers accordingly.

Previous to this release, the DNS tracker was disabled by default and had to be enabled by setting the DiscoveryConfigQosPolicy::dns_tracker_polling_period to a finite value. Now, that QoS setting is set to 20 seconds out-of-the-box, so Connext will discover any changes in hostname IP address resolution by default. Otherwise, a participant will continue to reach out to the outdated IP address to try and discover other participants, potentially preventing discovery from ever occurring with those peers.

See Using DNS Tracker to Keep Peer List Updated, in the RTI Connext Core Libraries User’s Manual, for more information.

5.1.3. Extensible Types compliance mask added to all APIs

The Extensible Types compliance mask and its corresponding APIs have been added to the Java, C#, and Python APIs, having previously been only in the C, Traditional C++, and Modern C++ APIs. See Extensible Types Compliance Mask in the Connext Core Libraries Extensible Types Guide for more information.

5.1.4. Updated code generation for 8-bit integer types

The code generation process for 8-bit integer types (octet, int8, and uint8) defined in IDL now distinguishes their internal representations within the TypeCode. While this update does not affect the functionality or usage of the generated code, we are providing this information for users who may observe these internal differences.

Specifically, in the Python API, the IDL octet type now generates a distinct type: idl.octet. This new type is functionally equivalent to idl.uint8. This change was necessary to accurately represent the different 8-bit integer types in internal structures such as the TypeCode.

5.1.5. Application no longer fails if platform does not support SOCKET_BUFFER_SIZE_OS_MAX

Attempts to use the send_socket_buffer_size SOCKET_BUFFER_SIZE_OS_MAX option (for example, NDDS_TRANSPORT_UDPV4_SOCKET_BUFFER_SIZE_OS_MAX) on platforms that do not support it caused the application to fail.

Now, when you set the SOCKET_BUFFER_SIZE_OS_MAX option on an unsupported platform, the application will log an error message and fall back to using the default socket buffer size. This change ensures that platform-specific configurations do not disrupt execution or prevent configuration profiles from being shared across environments.

See Setting Builtin Transport Properties with the PropertyQosPolicy in the RTI Connext Core Libraries User’s Manual for more information on the send_socket_buffer_size options.

5.1.6. Improved throughput when disable_positive_acks field in DataReaderProtocol QoS policy set to TRUE

This release improves application throughput when there are DataReaders configured with the disable_positive_acks field in the  DataReaderProtocol QoS policy set to TRUE.

The performance improvement is more noticeable with transient local configurations when there are a large number of samples in the DataWriter queue.

5.1.7. New metadata fields for custom filters in modern C++, Java, and Python

This release introduces support for filtering based on the following metadata fields when developing custom filters in modern C++, Java, and Python:

• sample_identity

• source_guid

• related_source_guid

• related_reader_guid

See Custom Content Filters in the RTI Connext Core Libraries User’s Manual for more information.

5.1.8. TCP Transport now uses POLL socket monitoring by default on Linux systems, offering significantly better responsiveness

This release changes the default socket monitoring mechanism for the TCP Transport on Linux architectures from SELECT to POLL . The new POLL-based socket monitoring (currently only supported for Linux architectures) offers significantly better responsiveness when handling socket events and raises the maximum number of sockets supported by TCP Transport on Linux architectures from 1024 to 32768 (see related fix COREPLG-756 in the Transports section of “What’s Fixed in 7.6.0”).

See socket_monitoring_kind in TCP/TLS Transport Properties, in the RTI Connext Core Libraries User’s Manual, for more information.

5.1.9. Decreased bandwidth usage when not actively debugging remote systems

Previously when using the Remote Debugging feature in Admin Console, Monitoring Library 2.0 sent all telemetry data generated by a Connext application to Collector Service. Now, telemetry data is sent only if an active Admin Console session requests the data, reducing unnecessary network traffic and improving system efficiency.

See Remote Debugging, in the Admin Console User’s Manual, for more information.

5.1.10. New built-in profile makes it easier to monitor Connext applications across geographically separated networks

This release introduces a new built-in profile called BuiltinQosLib::Generic.Monitoring2.WAN, which allows connecting to a Collector Service instance over the WAN using the RTI Real-Time WAN Transport. Connecting over the WAN enables you to use Observability Framework to monitor and collect telemetry data from Connext applications that are distributed across geographically separated networks, even when they are behind NATs. The new profile makes it easier to set up the connection over the WAN.

For example:

<qos_library name="MyQosLibrary">
     <qos_profile name="MyApplicationProfile" is_default_participant_factory_profile="true">
         <participant_factory_qos>
             <monitoring>
                 <enable>true</enable>
                 <distribution_settings>
                     <dedicated_participant>
                         <collector_initial_peers>
                             <element>udpv4_wan://38.21.45.34:4500</element>
                         </collector_initial_peers>
                         <participant_qos_profile_name>
                             BuiltinQosLib::Generic.Monitoring2.WAN
                         </participant_qos_profile_name>
                     </dedicated_participant>
                 </distribution_settings>
             </monitoring>
         </participant_factory_qos>
     </qos_profile>
 </qos_library>

For additional information, see Connecting to a Collector Service Over a WAN in the Observability Framework User’s Manual.

5.1.11. Third-Party Software Changes

The following third-party software is now used by Connext:

Table 5.1 New Third-Party Software

Third-Party Software	Version
BearHttpsClient	0.2.8
json-builder	Commit ID fffd849

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

Table 5.2 Third-Party Software Upgrades

Third-Party Software	Old Version	New Version
Expat	2.6.3	2.7.1
SQLite	3.39.4	3.50.2

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.