1 What's New in 7.1.0

RTI® Connext® 7.1.0 is a feature release based on release 7.0.0. See the Connext Releases web page on the RTI website for more information. This document highlights new features, platforms, and improvements in Connext, including the Core Libraries, for 7.1.0.

For what's fixed in the Core Libraries for 7.1.0, see the RTI Connext Core Libraries Release Notes.

For backward compatibility information between 7.1.0 and previous releases, see the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation).

Table 1.1 Release 7.1.0 Highlights

	Monitor Health of Connext Applications Using New Connext Observability Framework (Experimental) Provides a holistic solution for collecting telemetry data (metrics and logs) scalably, delivering the data to a host where it can be aggregated and visualized.
	Graphical Data Publishing (Experimental) Allows writing data to a user Topic, using a lightweight language binding (Python) to update the fields. See the RTI Admin Console Release Notes.
	Lightweight Security Provides an option for pragmatic and minimal security enforcement: message authentication and encryption to address DDS specification vulnerability (where initial packets are not protected) and an improved security model for domain bootstrapping. See the RTI Security Plugins Release Notes.
	Support for Dynamic Certificate Expiration When a certificate expires, certificate owners will be automatically removed, enabling long-running, uninterrupted operation of Connext secure systems. See the RTI Security Plugins Release Notes.
	RTI Routing Service in RTI System Designer RTI System Designer has new views for creating a Routing Service configuration in System Designer. See the RTI System Designer Release Notes.
	Enable Consistent View of Instance States Despite Disruptions to Connectivity, using New QoS Parameter (Experimental) When an application regains liveliness after a disruption (such as connectivity loss), the state of all the instances subscribed to that application transition back to their state before the disconnection.
	Support for OpenSSL 3.0 See the RTI Security Plugins Release Notes.
	Simple Participant Discovery Protocol 2.0 Improvements Enhancements have been made to the SPDP 2.0 option, which improves scalability with large numbers of DomainParticipants by sending optimized match and liveliness messages.

For what's new and fixed in other products included in the Connext suite, see those products' release notes on https://community.rti.com/documentation or in your installation. Or find those products' release notes here:

• RTI Connext Core Libraries Release Notes
• RTI Code Generator Release Notes
• RTI Routing Service Release Notes
• RTI Recording Service Release Notes
• RTI Persistence Service Release Notes
• RTI Web Integration Service Release Notes
• RTI Launcher Release Notes
• RTI Admin Console Release Notes
• RTI Monitor Release Notes
• RTI Shapes Demo User's Manual
• RTI System Designer Release Notes
• RTI Real-Time WAN Transport Release Notes
• RTI Security Plugins Release Notes
• RTI Limited Bandwidth Plugins Release Notes
• RTI Cloud Discovery Release Notes

See also 1.8 Product Availability Changes.

1.1 Monitor Health of Connext Applications Using New Connext Observability Framework (Experimental)

The Connext Observability Framework is a holistic solution that provides deep visibility into the current and past states of Connext applications, using telemetry data such as logs and metrics. This visibility makes it easier to proactively identify and resolve potential issues, providing a higher level of confidence in the reliable operation of the system.

The Connext Observability Framework consists of three key components:

• RTI Observability Library allows instrumenting a Connext application to emit telemetry data. The library also accepts remote commands (via the dashboards) to change the set of emitted telemetry data at runtime.
• RTI Observability Collector Service scalably collects and distributes telemetry data from individual Connext applications all the way to third-party telemetry backends, such as Prometheus® for metrics and Grafana® Loki™ for logs.
• RTI Observability Dashboards provide a way to visualize the telemetry data collected from Connext applications using a set of reference Grafana dashboards that you can customize or use as an example to enhance and build dashboards in the platform of your choice.

In this release, RTI supports Prometheus as the time-series database to store Connext metrics and Grafana Loki as the log aggregation system to store Connext logs. As OpenTelemetry is gathering widespread support in the observability industry, in future releases the Observability Framework will support OpenTelemetry to help integrate with various observability backends.

Note: All product components in the Observability Framework are experimental, so do not deploy them in production.

Figure 1.1: Observability Framework Architecture

Observability Framework use cases include:

• Debugging: find the cause of an undesired behavior or determine if the system meets performance needs during development.
• CI/CD Monitoring: assess the performance impact of code or configuration changes.
• Monitoring-deployed applications: confirm that your systems are running as expected and fix potential performance issues proactively.

RTI Connext Observability Framework must be downloaded and installed separately. Check the RTI Customer portal or contact support@rti.com for information on how to obtain an Observability Framework package.

For information on installing the Observability Framework, as well as a step-by-step guide for running it with the included example, see the RTI Observability Framework documentation.

1.1.1 Observability Library

The RTI Observability Library allows instrumenting a Connext application to emit telemetry data (logs and metrics).

The RTI Observability Library includes the following key features:

• Collection and emission of Connext metrics and logs. Secure logs will be supported in future releases.
• Configuration using a new MONITORING QoSPolicy. The QoS policy can be set programmatically or via XML.
• Runtime changes to the set of emitted telemetry data using remote commands coming from the RTI Observability Collector. In this release, the library only allows changing the emission and generation log verbosity level for a Connext application.
• Ability to enable and disable use of the RTI Observability Library at runtime by changing the MONITORING QoSPolicy.
• Lower overhead compared to the RTI Monitoring Library (described in RTI Monitoring Library, in the RTI Connext Core Libraries User's Manual).

To learn more, see RTI Observability Library, in the RTI Connext Core Libraries User's Manual. See also the RTI Observability Framework documentation.

1.1.2 Observability Collector Service

The RTI Observability Collector Service scalably collects telemetry data emitted by the RTI Observability Library in a Connext application. The service can work in two modes:

• Forwarder: In this mode, the Collector forwards the telemetry data from a Connext application to other Collector instances. This mode is not supported in this release.
• Storage: In this mode, Collector stores the telemetry data in a third-party observability backend. In this release, the observability backend is Prometheus for metrics and Grafana Loki for logs. Future releases will allow integration with other third-party backends by using OpenTelemetry.

The Observability Collector Service includes the following key features:

• Collection and filtering of telemetry data emitted by Connext applications (using the RTI Observability Library) or other Collectors. This release does not provide filtering capabilities.
• Storage of telemetry data in third-party backends: Prometheus for metrics and Grafana Loki for logs.
• Remote command forwarding from the Observability dashboards to the Connext applications and resources to which the commands are directed. This release only allows forwarding commands that change the logging verbosity of Connext applications.

1.1.3 Observability Dashboards

This release includes a set of hierarchical Grafana dashboards that are built to alert you when a problem occurs and facilitate root cause analysis. The dashboards get the telemetry data that they visualize from the third-party backends in which RTI Collector Service stores the data.

The first layer of the Grafana dashboards provides a health status summary by focusing on five golden signals: Bandwidth, Saturation, Data Loss, System Errors, and Delays.

Figure 1.2: Grafana Dashboard with Errors

Starting on the first dashboard, you can get additional details on the error conditions by clicking on any of the golden signals showing a problem.

The top-level dashboard also provides access to the system logs and provides information about the number of entities running in the system.

1.2 Enable Consistent View of Instance States Despite Disruptions to Connectivity, using New QoS Parameter (Experimental)

The NOT_ALIVE_NO_WRITERS state for an instance indicates that there are no active DataWriters that are currently updating an instance. This can occur because all of the DataWriters that were publishing the instance have unregistered themselves from the instance or they all have become not alive (through losing liveliness or being deleted). In this case, the DataReader will set the state of the instance to NOT_ALIVE_NO_WRITERS.

In previous releases, if the DataReader rediscovered a DataWriter previously publishing the instance, the state of the instance was not updated on the DataReader until the DataWriter sent a new sample of the instance. Instead, the instance would stay in the NOT_ALIVE_NO_WRITERS state. This could lead to inconsistent instance states: a late-joining DataReader (with a durability of TRANSIENT_LOCAL or higher) would have the correct instance state by virtue of discovery and receiving the samples from the DataWriter, whereas existing DataReaders would have the wrong state until they received a new sample. See Figure 1.3: Behavior without Instance State Consistency Enabled.

Figure 1.3: Behavior without Instance State Consistency Enabled

In this release, Connext provides a new, experimental QoS setting, instance_state_recovery_kind, in the RELIABILITY QoS Policy, that enables a DataReader to update the instance state when a DataWriter is rediscovered without the DataReader's having to receive samples for the instance. With instance state recovery enabled, when a DataWriter is rediscovered, the DataReader will send it a request for any instance state transitions that were missed while the two endpoints were disconnected. The DataWriter will send a response. The DataReader uses the information in the response to set the state of the instances to the same state they would have been in had the disconnection never occurred. Everything happens without any intervention from you, other than setting the QoS. Any instance state transitions that occur due to the DataWriter's response sample are presented to the user application in the form of samples with the valid_data flag set to FALSE in the associated SampleInfo.

Figure 1.4: Behavior with Instance State Consistency Enabled

For details, see the "Transition after NOT_ALIVE_NO_WRITERS" section in "Instance States," in the RTI Connext Core Libraries User's Manual.

1.3 Simple Participant Discovery Protocol 2.0 Improvements

The following improvements have been made to the experimental Simple Participant Discovery Protocol (SPDP2) introduced in release 7.0.0. See (Experimental) Simple Participant Discovery 2.0, in the RTI Connext Core Libraries User's Manual for more information.

1.3.1 Improved bandwidth usage through optimal sending of bootstrap messages

There have been several improvements to bandwidth usage when using the experimental Simple Participant Discovery Protocol 2.0 (SPDP2).

Previously, when a DomainParticipant discovered a remote DomainParticipant, it continued to send bootstrap messages (DATA(Pb)) to any locators that belonged to the remote participant. But this is unnecessary, because the remote participant will drop any bootstrap messages it receives from a participant it has fully discovered.

In 7.1.0, a participant stops sending bootstrap messages to all unicast locators that belong to a remote participant once the participant has received the remote participant’s full configuration in a configuration message (DATA(Pc)). This includes any unicast locators that are initial peers. The participant also removes any multicast locators that the remote participant is using that are not initial peers. The participant continues to send bootstrap messages to any multicast locators that the remote participant is using if they are also part of the initial peers list. This allows the participant to still discover any other participants with the same multicast receive address.

When the local participant receives updated locators from a remote participant after an IP mobility event, or the local participant removes the remote participant (for example after losing liveliness or receiving a dispose message from the remote participant), the local participant will once again send bootstrap messages to any locators that belonged to the remote participant that were also initial peers.

These changes in behavior result in lower bandwidth usage, because participants send fewer bootstrap messages once a system is fully discovered and is at a steady state.

1.3.2 Differentiate between bootstrap messages and configuration messages more easily with new flag in ParticipantBuiltinTopicData

Previously, there was no way to tell whether a message received by a DomainParticipant contained the full configuration of the remote DomainParticipant or only the bootstrapping information. Now, if you are using SPDP2 (and have installed a listener on the ParticipantBuiltinTopicData builtin DataReader and set ignore_default_domain_announcements to FALSE—the default is TRUE), you will receive a sample on the ParticipantBuiltinTopicData builtin DataReader both when the participant receives a bootstrap message and when the participant receives a configuration message.

A partial_configuration flag has been added to the ParticipantBuiltinTopicData. When this flag is TRUE, only the bootstrapping information in the sample is valid. When this flag is FALSE, the sample contains both the bootstrapping and configuration information of the remote participant. See Built-in DataReaders, in the RTI Connext Core Libraries User's Manual for which fields are valid when this flag is set to TRUE.

1.3.3 Configure how configuration messages are sent using new QoS

In SPDP2, when two participants have received each other’s bootstrap messages, they will exchange the rest of their configuration over a reliable channel using a configuration message. SPDP2 uses the ParticipantConfigBuiltinTopicData builtin Topic and associated builtin DataWriter and DataReader to send those configuration messages.

In 7.0.0, when SPDP2 was first released, the ParticipantConfigBuiltinTopicData builtin DataWriter and DataReader used the same QoS settings as the PublicationBuiltinTopicData builtin DataWriter and DataReader. Now, the ParticipantConfigBuiltinTopicData builtin DataWriter and DataReader have their own QoS settings. These QoS settings are used to tune the builtin DataWriter and DataReader that sends and receives the configuration messages.

The new QoS settings available in the DISCOVERY_CONFIG QosPolicy for the DomainParticipant are as follows:

• participant_configuration_writer
• participant_configuration_writer_data_lifecycle
• participant_configuration_writer_publish_mode
• participant_configuration_reader
• participant_configuration_reader_resource_limits

For details, see DISCOVERY_CONFIG QosPolicy in the RTI Connext Core Libraries User's Manual.

1.3.4 remove_peer() API does not work with SPDP2 (known limitation)

The remove_peer() API is no longer supported when using SPDP2. Attempting to use remove_peer() will fail if called on a DomainParticipant using SPDP2.

1.4 API Improvements

1.4.1 Python API Improvements

1.4.1.1 Consistency and ease of use for read/take operations of IDL-based readers (dds.DataReader) and DynamicData readers

In previous releases, the read/take operations of IDL-based readers (dds.DataReader) and DynamicData readers (dds.DynamicData.DataReader) were not equivalent. This release makes the reader APIs equivalent with the following changes:

Changes to dds.DynamicData.DataReader and the builtin discovery readers (such as dds.ParticipantBuiltinTopicData.DataReader):

• The methods read() and take() now return copies of the data in a list of data/info named tuples, instead of loaned data and info in a LoanedSamples collection.
• The new methods read_loaned() and take_loaned() return loaned data and info in a LoanedSamples collection.
• The new methods read_data() and take_data() return copies of data in a list of data objects. The methods read_valid() and take_valid() have been removed.
• The new methods take_async() and take_data_async() provide copies of the data and data/info asynchronously.
• The methods take_next() and read_next() have been removed. Use take() and read() instead, and to read only one sample, use select() with a max_samples of 1.
• In most cases the versions that copy the data provide better performance than read_loaned() and take_loaned(), unless the data samples are very large.

Changes to dds.DataReader:

• The methods read() and take() continue to return copies, but they now return a list of named tuples, instead of a list of unnamed tuples, so the following code is now possible:

for sample in reader.take():

    data = sample.data

    info = sample.info

    do_something(data, info)

Note that this code continues to work as before:

for data, info in reader.take():

    do_something(data, info)

The same changes have been made to each DataReader’s Selector class.

1.4.1.2 XML-Based Application Creation now fully supported, with added support for use of IDL types

This release adds the ability to use Python classes (derived from IDL) as the topic-type in the XML definition of DataReaders and DataWriters. This functionality was missing in the Python API in the previous release. Adding this functionality completes support in the Python API for XML-Based Application Creation.

For more information, see the API Reference: API Overview, XML Application Creation.

1.4.2 Topic-types can now be registered with a custom name

In previous releases, in the Python API the dds.Topic constructor didn't provide an argument to specify the name of the type to be registered. The actual name of the class was used. While using a different type name is usually not necessary, there are some situations where it is needed (for example, to interoperate with applications using a different version of the type and the type definition can't be used to determine compatibility).

This release adds an extra optional argument to the Topic constructor that allows specifying the name to register the type with.

1.4.3 Set InitialObjectsPerThread QoS parameter in C# API

For completeness, InitialObjectsPerThread was added to SYSTEM_RESOURCE_LIMITS QoS Policy. This allows you to control the amount of memory initially allocated in each thread for thread-specific storage. However, the amount of thread-specific storage is now automatically managed by Connext, so it is very unlikely that you will need to set this parameter.

1.4.4 New non-throwing variants provided for some critical functions in Modern C++ API

Some applications need to ensure that their critical code paths do not allocate memory and therefore can't throw exceptions. For this reason, the DataReader read() and take() operations as well as the DataWriter write() operation now include variants with the noexcept guarantee:

Existing Function	New Function
DataReader::take(), DataReader::read()	DataReader::take_noexcept(), DataReader::read_noexcept()
DataReader::Selector::take(), DataReader::Selector::read()	DataReader::Selector::take_noexcept(), DataReader::Selector::read_noexcept()
DataWriter::write()	DataWriter::write_noexcept()

The new noexcept functions return a Result type, which contains the original return type plus a return code that provides information about the result of the operation. The error return codes in a Result object correspond to the exceptions that the throwing variants would throw in case of error.

See the API Reference for more information on each of these functions and on the new Result type.

1.5 Debuggability Improvements

1.5.1 Discovery snapshots now show domain tags and partition information

Discovery snapshots readability has been improved, and now they show information about domain tags and partitions. See Discovery Snapshots, in the RTI Connext Core Libraries User's Manual for more information.

1.5.2 Debug root cause of file open and close operations easily with enhanced log messages

File opening/closing error messages have been updated to contain information about the root cause of the error.

Previously, the error message when an open operation failed was as follows:

Failed to open file 'example.xml'

Now opening and closing error messages will follow this format:

OPEN FILE FAILURE | example.xml with error code 2 (No such file or directory) in DDS_XMLFileInfoList_assertFile

1.5.3 Manually enable or disable logging backtrace upon SIGSEGV signal from a Connext application, using new property

For debuggability purposes, Connext applications log a backtrace when a SIGSEGV signal is triggered.

In this release, a new property, dds.participant.enable_backtrace_upon_sigsegv, allows you to manually enable or disable the use of this logging feature. (See PROPERTY QosPolicy (DDS Extension), in the RTI Connext DDS Core Libraries User's Manual.) By default, logging of the backtrace will be disabled in release libraries, but enabled in debug libraries. See "Potential hang upon SIGSEGV signal from a Connext application" (CORE-12794) in the RTI Core Libraries Release Notes.

The accepted values for the new property are "auto" for the default behavior (backtrace enabled only in debug libraries), "true" for enabling the logging of the backtrace in both debug and release libraries, and "false" for disabling it in both release and debug libraries.

1.5.4 More easily debug failures due to DestinationOrder by source timestamp mismatches, with enhanced log messages

When addSample fails due to a DestinationOrder by source timestamp mismatch, Connext now logs the two timestamps that were compared. This message is generated at the warning logging level. Additionally, timestamp comparison logs now display the timestamps at a microsecond resolution.

1.6 Platform and Build Changes

1.6.1 Support for .NET/C# API on macOS Systems with Arm v8 CPUs

The Connext .NET/C# API is now supported on macOS® systems with Arm® v8 CPUs. Previously, the .NET/C# API was only supported on macOS systems with x64 CPUs.

1.6.2 New Platforms

RTI has validated that the Connext libraries for Red Hat® Enterprise Linux 8 systems (x64Linux4gcc7.3.0) also work on Red Hat Enterprise Linux 9 systems.

The architecture x64Darwin17clang9.0 has been replaced with x64Darwin20clang12.0.

Table 1 New Platforms

OS	OS Version	CPU	Toolchain	RTI Architecture
Linux	Red Hat Enterprise Linux 9	x64	gcc 7.3.0	x64Linux4gcc7.3.0
macOS	macOS 11, 12	x64	clang 12.0, 13.0	x64Darwin20clang12.0

1.6.3 Removed Platforms

This release removes support for the following platforms. Note that newer versions of macOS (macOS 11 and 12) are supported. Support for VxWorks will return in a future release.

Table 2 Removed Platforms

OS	OS Version	CPU	Toolchain	RTI Architecture
macOS	macOS 10.13-10.15	x64	clang 9.0, 10.0, 11.0	x64Darwin17clang9.0
VxWorks	VxWorks 21.11	x64	llvm 12.0.1.1	x64Vx21.11llvm12.0.1.1 x64Vx21.11llvm12.0.1.1_rtp

1.6.4 Added QNX7.1 support to FindRTIConnextDDS script

The "Find Package" script (FindRTIConnextDDS.cmake) now supports building the armv8QNX7.1qcc_gpp8.3.0 architecture.

1.6.5 New FindPackage component allows building the Security Plugins against wolfSSL

A new component, security_plugins_wolfssl, has been added to the "Find Package" script (FindRTIConnextDDS.cmake) in order to link the RTI Security Plugins library against wolfSSL®. The component security_plugin continues to link against OpenSSL®.

1.6.6 New components and imported target libraries for Cloud Discovery Service, Persistence Service and Web Integration Service added to "FindPackage" CMake script

As mentioned in their release notes, Cloud Discovery Service, Persistence Service, and Web Integration Service are now installed with target libraries. Those target libraries have been added to the "Find Package" (FindRTIConnextDDS.cmake) script:

• cloud_discovery_service components:
• RTIConnextDDS::cloud_discovery_service_c
• RTIConnextDDS::cloud_discovery_service_cpp2

• persistence_service component:
• RTIConnextDDS::persistence_service_c

• web_integration_service component:
• RTIConnextDDS::web_integration_service_cpp2

1.7 Deprecations and Removals

This section describes products, features, and platforms that are deprecated or removed starting in release 7.1.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. By specifying that an item is deprecated in this release, RTI is hereby providing customer notice that RTI reserves the right after one year from the date of this release and, with or without further notice, to immediately terminate maintenance (including without limitation, providing updates and upgrades) for the item, and no longer support the item, in a future release.

This section serves 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.

1.7.1 Monitoring Library deprecated in this release

In this release, RTI announces the deprecation of the RTI Monitoring Library (described in RTI Monitoring Library, in the RTI Connext Core Libraries User's Manual) and RTI Monitor. RTI is introducing a new Connext Observability Framework (see 1.1 Monitor Health of Connext Applications Using New Connext Observability Framework (Experimental)); in the future, this new framework will replace the current Monitoring Library.

If you want to start monitoring your deployed systems using a monitoring API, you should use the new library; if you're already using the current Monitoring Library API and plan to move to future Connext releases, you should plan your migration now. RTI will continue to support the current Monitoring Library and Monitor for customers using 6.1.x. This deprecation notice applies to customers using 7.1 and later.

1.7.2 Removed ability to share a database connection in Persistence Service and durable writer history

This release removes the ability to share a database connection in RTI Persistence Service (which is done by setting the tag <share_database_connection> to true for a <persistence_group>). It also removes the ability to share a database connection when using durable writer history and setting the property dds.data_writer.history.odbc_plugin.builtin.shared to 1.

Note that sharing a database connection was only allowed for external databases, and support for external databases was removed in 7.0.0 (see 2.12.4 Durable writer history, durable reader state, and Persistence Service no longer support external databases).

1.8 Product Availability Changes

1.8.1 RTI Limited Bandwidth Endpoint Discovery now installed with RTI Connext Professional

Starting in 7.1.0, RTI Limited Bandwidth Endpoint Discovery (LBED) is installed with the RTI Connext Professional bundle. You no longer need to purchase and install LBED separately. It is installed with your rti_connext_dds-7.1.0-pro-<host or target>-<host platform or target architecture>.<extension or rtipkg> bundle. Because of this change, LBED is also no longer included with the RTI Limited Bandwidth Plugins. See Limited Bandwidth Endpoint Discovery, in the RTI Connext Core Libraries User's Manual and the RTI Limited Bandwidth Endpoint Discovery User's Manual.

1.8.2 RTI Web Integration Service now installed with RTI Connext Professional

Starting in 7.1.0, RTI Web Integration Service is installed with the RTI Connext Professional bundle. (It was always included with Professional, but you had to install it separately.) You no longer need to install Web Integration Service separately. It is installed with your rti_connext_dds-7.1.0-pro-<host or target>-<host platform or target architecture>.<extension or rtipkg> bundle. For more information, see the documentation for Web Integration Service in <NDDSHOME>/doc/manuals/connext_dds_professional/services/web_integration_service. See the Installation chapter.

1.8.3 Cloud Discovery Service now shipped as host + target, consistent with other Infrastructure Services, by providing target-specific libraries/executables

RTI Cloud Discovery Service is now shipped in two parts, as a host and a target package. This change brings Cloud Discovery Service in line with how other Connext packages are structured and ensures that you have target-specific libraries when using the service-as-a-library functionality. See the RTI Cloud Discovery Service documentation for more information.

1.8.4 TLS Support now included with Connext Secure and Connext Anywhere

In release 7.1.0, RTI TLS Support is now included with the purchase of the Connext Secure and Connext Anywhere bundles. It is still installed separately. See the RTI TLS Support Installation Guide.

1.9 Other

1.9.1 Connext Now Searches for Included XML Configuration Files in Directory where File is Located

This release improves the way Connext searches for the XML contained in the file attribute of the <include> XML tag.

In previous releases, Connext only searched the current working directory for XML files. For example, assume these three files:

File1.xml (located in the current working directory)

<dds>

    <types>

        <include file=”./nested/File2.xml"/>

        …

    </types>

</dds>

nested/File2.xml

<dds>

    <types>

        <include file=”File3.xml"/>

        …

    </types>

</dds>

nested/File3.xml

<dds>

    <types>

        …

    </types>

</dds>

Previously, Connext could not parse File2.xml, because in File2.xml, the path to File3.xml is given as relative to File2.xml's current directory, but the parser wasn't looking in that directory for File3.xml; it was looking only in the current working directory (where File1.xml is) for File3.xml. In this release, Connext now also considers the directory containing the current file being parsed (File2.xml) to resolve the path for its included files (File3.xml).

The search order for included files is now as follows:

1. (new step) Connext searches for the included files contained in a file in the directory where that file is located.
2. Connext searches for the included files in the current working directory.

Currently, this feature is only supported on the following systems, for the platforms listed in Supported Platforms, in the RTI Connext Core Libraries Release Notes:

• AIX®
• Android™
• Linux® (except for POSIX®-compliant platforms for RTI Connext TSS)
• macOS®
• Windows®
• QNX®

1.9.2 Connext Now Uses RTPS 2.5

RTI has updated the RTPS wire protocol version number that Connext announces in messages it puts on the wire, from version 2.3. to version 2.5. This is a result of RTI's work towards supporting the RTPS protocol with RTPS version 2.5 features. For details, see Compatibility, in the RTI Core Libraries Release Notes.