2.1 What's New in 7.2.0

RTI® Connext® 7.2.0 is a feature release based on release 7.1.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.2.0.

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

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

Table 2.1 Release 7.2.0 Highlights

	Support for systems running beyond 2038 Connext applications now support systems beyond 2038, following the latest OMG DDS and RTPS specifications. This update enables Connext applications to run smoothly until 2106.
	Python API Now Fully Productized and Supported Python joins the ranks as a fully supported API along with C, Modern C++, Java, and .NET. This release also adds pip-based installation and support for Request-Reply.
	Connext Observability Framework Enhancements (Experimental) Observability Framework's integration with OpenTelemetry enables flexible storage and analysis of telemetry data in a variety of third-party observability backends. Developers can leverage OpenTelemetry's vast ecosystem to store and analyze telemetry data in their preferred systems.
	Graphical Data Publishing in Admin Console Enhancements include altering QoS after publication, dragging and dropping samples between sample log and sample queue, importing and exporting samples, and more. See the RTI Admin Console Release Notes.
	Lightweight Security Enhancements Connext applications running the regular Security Plugins can now interoperate with Lightweight Security applications. Additionally, Lightweight Security can be applied to Cloud Discovery Service and Real-Time WAN Transport, ensuring secure data transmission in cloud environments. See the RTI Security Plugins Release Notes.
	Dynamic Certificates Renewal and Revocation Enhancements Dynamic Access Control can be created based on dynamic Identity Certificates, Certificate Revocation Lists (CRL), or a whitelist of Identity Certificate Subject Names. Furthermore, Dynamic Certificates are seamlessly integrated with RTI Infrastructure Services and Admin Console. See the RTI Security Plugins Release Notes.
	Instance State Consistency Enhancements Instance state consistency is now integrated with the Security Plugins and with Admin Console’s data visualization feature. It also has improved resource management and other features.
	Simple Participant Discovery Protocol 2.0 Enhancements The upgraded SPDP2 (Simple Participant Discovery Protocol 2.0) enhances robustness and seamless integration with the Security Plugins. It introduces support for IP mobility events, secure participant sample signature verification, reliable partition change handling, and compatibility with Cloud Discovery Service.

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 release notes here:

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

See also 2.1.9 Product Availability Changes.

2.1.1 Connext Observability Framework Enhancements (Experimental)

This release adds the following new capabilities to RTI Connext Observability Framework, which was introduced in release 7.1.0 (see 2.2.1 Monitor Health of Connext Applications Using New Connext Observability Framework (Experimental)).

See also the RTI Observability Framework documentation.

2.1.1.1 Support for most observability backends with OpenTelemetry integration

For details, see the RTI Observability Framework Release Notes.

2.1.1.2 Secure communications among Observability Framework components

For details, see Security, in the RTI Observability Framework documentation and the RTI Observability Framework Release Notes.

2.1.1.3 Name change from "RTI Observability Library" to "RTI Monitoring Library 2.0"

This release changes the name of the "RTI Observability Library" to "RTI Monitoring Library 2.0."

This change includes changing the names of builtin QoS profiles. If your application references these profiles, you should update the names accordingly. See the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation) for details.

2.1.1.4 Configure initial log forwarding verbosity via MONITORING QoS policy

The forwarding verbosity controls the level of log messages an application forwards to RTI Observability Collector Service, for use by Observability Framework.

In the previous release, this verbosity level could only be changed through the Dashboard, with "warnings" as the default value. In this release, applications' initial forwarding verbosity level can be configured using a new field in the MONITORING QoS policy: monitoring::telemetry_data::logs::middleware_forwarding_level (the rest of the Syslog Facilities are not supported yet). This way, you can forward log messages with the desired verbosity right away from the beginning, rather than using the Dashboard to change the verbosity later.

This verbosity level can be specified in code or through XML (USER_QOS_PROFILES.xml):

<participant_factory_qos>

    <monitoring>

        ....

        <telemetry_data>

            <logs>

                <middleware_forwarding_level>NOTICE</middleware_forwarding_level>

            </logs>

        </telemetry_data>

    </monitoring>

</participant_factory_qos>

For more information on the middleware_forwarding_level field, see MONITORING QosPolicy, in the RTI Connext Core Libraries User's Manual.

2.1.1.5 Set Collector initial peers in MONITORING QoS policy

RTI Monitoring Library 2.0 (previously known as the RTI Observability Library) creates a dedicated DomainParticipant in the Observability Domain ID to distribute telemetry data for use by Observability Framework.

Setting the initial peers list for this DomainParticipant wasn't trivial. You had to create an additional QoS profile inheriting from BuiltinQosLib::Generic.Observability, set the initial peers list in that new profile, and refer to that profile using the distribution_settings.dedicated_participant.participant_qos_profile_name field in the MONITORING QoS policy.

Since setting the initial peers pointing to the RTI Observability Collector Service is always required, in this release Connext now has a new field, collector_initial_peers, under distribution_settings.dedicated_participant, that makes the configuration easier.

Here is an example that shows how to set the field in an XML configuration file:

<qos_profile name="MyApplicationProfile">

    <participant_factory_qos>

        <monitoring>

            <enable>true</enable>

            <distribution_settings>

                <dedicated_participant>

                    <collector_initial_peers>

                        <element>192.168.1.1</element>

                    </collector_initial_peers>

                </dedicated_participant>

            </distribution_settings>

        </monitoring>

    </participant_factory_qos>

</qos_profile>

For more information on the collector_initial_peers field, see MONITORING QosPolicy, in the RTI Connext Core Libraries User's Manual.

2.1.2 Instance State Consistency Enhancements

This release improves the new capability introduced in 2.2.2 Enable Consistent View of Instance States Despite Disruptions to Connectivity, using New QoS Parameter (Experimental).

Instance state consistency is no longer experimental starting in release 7.2.0.

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

2.1.2.1 Instance state consistency with security fully supported

Security can now be enabled in systems that enable instance state consistency.

A new domain-level rule, instance_state_consistency_protection_kind, has been added to the governance file in the Security Plugins that allows the protection kind of the instance state consistency channel to be configured. If instance_state_consistency_protection_kind is not set in the governance file, the protection kind is inherited from discovery_protection_kind. When the protection kind is inherited from discovery, the instance_state_consistency_protection_kind is not propagated during discovery.

Note that the instance_state_consistency_protection_kind only configures the submessage protection used by the channel. The payload protection uses the crypto data from the DataWriter with which the DataReader has regained liveliness. This is to ensure that the topic-level security configured in a system is respected.

To enable security with instance state consistency, the service request channel must also have security enabled (since the service request channel is used to send the request for instance state data).

For more information about instance_state_consistency_protection_kind, see instance_state_consistency_protection_kind (domain_rule), in the RTI Security Plugins User's Manual.

2.1.2.2 Integration with Admin Console's data visualization feature

Admin Console's Instance Table will now attempt to recover and display samples that have transitioned back to the ALIVE state. Note that because only a single sample is kept for each instance, this recovery is not always possible. For example, if a different DataWriter with a lower strength publishes samples after the liveliness loss, then Admin Console's cached sample will be from the lower-strength DataWriter and so will not show in the Instance Table. However, if the cached sample is from the same DataWriter that is transitioning the instance to ALIVE, then the data will appear.

2.1.2.3 Instance state consistency now more robust

The following changes enhance robustness of the instance state consistency feature.

2.1.2.3.1 Instance key values now always available for dispose and "valid data" samples

You can now always call get_key_value to determine which instance has transitioned when a sample with valid_data=FALSE is received, as long as the instance has been seen by the DataReader before.

Previous to this change, if the instance had previously been detached, then a call to get_key_value would have failed to retrieve the key value. In the context of instance state consistency, this meant that when a writer of an instance regained liveliness after a network disconnection, and the instance transitioned back to ALIVE with valid_data=FALSE, it was not possible to call get_key_value to identify the instance that was transitioning back to ALIVE. Now, the key value can be retrieved in this situation as long as keep_minimum_state_for_instances=TRUE in the DataReader's DATA_READER_RESOURCE_LIMITS QoS policy.

2.1.2.3.2 Instance state consistency correctly handles instances removed from DataWriter queue during disconnection

In release 7.1.0, instances that were removed from the DataWriter queue during a disconnection may have transitioned to their last known state on the DataReader, resulting in inconsistent behavior. Now, instances that are removed from the DataWriter queue during a disconnection no longer transition to any state after a reconnection. This is because, during the disconnection, the DataReader may have missed an instance transition for the removed instance, and therefore the DataReader can't know which state to transition it to. Furthermore, the DataWriter can't tell the DataReader what the final state was because it has removed all information about that instance from its queue.

See "Transition after NOT_ALIVE_NO_WRITERS" section in "Instance States," in the RTI Connext Core Libraries User's Manual for a complete explanation of this and other special considerations.

2.1.2.4 Improvements in resource management while using instance state consistency

The following enhancements have been made to improve resource management related to instance state consistency:

• A new QoS setting, autopurge_remote_not_alive_writer_delay, prevents unbounded memory growth related to instance state consistency. See DATA_READER_RESOURCE_LIMITS QosPolicy (DDS Extension) in the RTI Connext Core Libraries User's Manual for more details.
• This release prevents unbounded memory growth on the DataWriter, which occurred when using instance state consistency in the previous release.

2.1.2.5 "Instance state recovery" feature and QoS name are now "instance state consistency"

The name of the "instance state recovery" feature has been changed to "instance state consistency" to more accurately reflect its benefit. This change includes renaming some fields (e.g., in the C API, instance_state_recovery_kind in the RELIABILITY QoS policy changed its name to instance_state_consistency_kind) and some values (e.g., DDS_RECOVER_INSTANCE_STATE_RECOVERY became DDS_RECOVER_INSTANCE_STATE_CONSISTENCY, and DDS_NO_INSTANCE_STATE_RECOVERY became DDS_NO_RECOVER_INSTANCE_STATE_CONSISTENCY).

2.1.3 Simple Participant Discovery Protocol 2.0 Enhancements

The following improvements have been made to the new feature described in 2.2.3 Simple Participant Discovery Protocol 2.0 Improvements.

For details on Simple Participant Discovery Protocol 2.0 (SPDP2), see Simple Participant Discovery 2.0, in the RTI Connext Core Libraries User's Manual.

SPDP2 is no longer experimental starting in release 7.2.0.

2.1.3.1 Improved partition change synchronization for enhanced discovery and liveliness in SPDP2

In previous releases of SPDP2, a partition change between two matching DomainParticipants that led to the DomainParticipants' not matching was sent reliably on the ParticipantConfigBuiltinTopicData Topic. However, the local DomainParticipant changing its partitions did not wait for the remote DomainParticipant to receive the partition change. If the local DomainParticipant configuration message containing the partition change was lost and the remote DomainParticipant discovery locator was not part of the local DomainParticipant's initial peers, the remote DomainParticipant would not discover the partition change until it lost liveliness with the local DomainParticipant.

This behavior has changed in release 7.2.0. Now, when using SPDP2, the local DomainParticipant will wait until the remote DomainParticipant acknowledges reception of the configuration change before fully removing the remote participant.

2.1.3.2 Enhanced liveliness communication with RTPS peer descriptors in SPDP2 improves liveliness with Cloud Discovery Service

DomainParticipants using Simple Participant Discovery Protocol 2.0 (SPDP2) were previously at risk of losing liveliness with any Infrastructure Service that was configured to communicate with an RTPS peer descriptor.

DomainParticipants use an RTPS peer descriptor in their initial peers when the participant needs to communicate with a service, but the service does not perform discovery with the participant. Participants now use RTPS peer descriptors to communicate with Cloud Discovery Service (CDS). In this case, a participant sends its participant announcements to CDS and CDS forwards those announcements to the other participants, but CDS will never send a participant announcement about itself and therefore will never perform participant discovery with the participant. Because participant discovery does not take place, the participant never sends liveliness messages to CDS.

Since the participant was previously only sending participant announcements at the participant_announcement_period, CDS may have lost liveliness with the participant if the participant_announcement_period was greater than the participant_liveliness_lease_duration.

A participant using SPDP2 will now send additional bootstrap messages to any RTPS peer descriptors in its initial peers at the participant_liveliness_assert_period if the participant_liveliness_assert_period is less than the participant_announcement_period. This allows the participant to maintain liveliness with any service by sending out updates at a period that is less than the participant_liveliness_lease_duration.

2.1.3.3 More easily enable SPDP2 using new QoS value in builtin_discovery_plugins

Previously, to enable SPDP2, you had to provide SPDP2 | SEDP as the builtin_discovery_plugins mask in the DISCOVERY_CONFIG QosPolicy. (SPDP2 must be enabled with an endpoint discovery plugin, such as the Simple Endpoint Discovery Protocol (SEDP).) A new value, SDP2, has been added to the valid inputs for this field to enable both SPDP2 and SEDP. This is consistent with the existing SDP value, which enables both SPDP and SEDP.

2.1.4 Python API Now Fully Productized and Supported

The Connext Python API is no longer experimental in this release. With release 7.2.0, it is now a fully supported language API and can be used in production systems.

Starting with this release, the Python API is installed with pip.

To get started with the Python API, see the Python language version of the RTI Connext Getting Started Guide. For further details, see the Python API Reference HTML documentation.

2.1.5 Other API Improvements

2.1.5.1 Request-Reply API for Python available

This release includes the Request-Reply API for Python. For more information see Request-Reply and Remote Procedure Calls, in the Python API Reference HTML documentation.

2.1.5.2 Modern C++ API

2.1.5.2.1 Support for sequences of wchars in DynamicData

A sequence of wchars can now be set using DynamicData::set_values. Previously, only uint16s could be in an array, but now there is the flexibility to use both.

2.1.5.2.2 Exception messages now contain the name of the exception type

Exceptions thrown by the Modern C++ API now contain the name of the exception in the what() description.

2.1.6 Support for systems running beyond 2038

Connext applications have added support for systems running beyond the year 2038. This update, which is compliant with the latest OMG Real-Time Publish-Subscribe (RTPS) specification, version 2.5 (and was introduced in version 2.3), now makes it possible to run Connext applications up to year 2106.

As part of this change, the seconds field of the DDS_Time structure has been updated from a 32-bit value to a 64-bit value. This change to the seconds field was made in anticipation of a future update to the OMG DDS specification, but for now the change is an RTI extension. Therefore, this change could affect portability of code between DDS vendors who follow the specification as it is today. See Secure BuiltinLoggingTopic renamed to BuiltinLoggingTypeV2 in the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation) for more information.

Year 2038 support applies only to this and future releases of Connext; there are currently no plans to backport it to previous releases.

2.1.7 Platform and Build Changes

This release adds support for the following platforms, compared to release 7.1.0.

To see which products support the new platforms, see Supported Platforms, in the RTI Connext Core Libraries Release Notes.

Table 2.2 New Platforms

OS	OS Version	CPU	Toolchain	RTI Architecture
VxWorks®	VxWorks 22.09	x64	llvm 13.0.1.3	x64Vx22.09llvm13.0.1.3 x64Vx22.09llvm13.0.1.3_rtp
Linux®	Ubuntu® 18.04 LTS	Arm® v7	gcc 7.5.0	armv7Linux4gcc7.5.0

Note: Ubuntu 18.04 LTS for Arm v7 is supported in release 6.1.1/6.1.2. It was not in release 7.0.0/7.1.0; now, it is added back in 7.2.0.

2.1.7.1 Support for Limited Bandwidth Plugins and Limited Bandwidth Endpoint Discovery on certain Linux Platforms

This release add supports for Limited Bandwidth Plugins and Limited Bandwidth Endpoint Discovery to these platforms when using Arm v8 CPUs:

• Ubuntu 18.04 LTS
• Ubuntu 22.04 LTS

The RTI architecture for these platforms is armv8Linux4gcc7.3.0.

2.1.7.2 Support for Security Plugins for wolfSSL 5.5.1 on certain Linux platforms

Previously, the Security Plugins for wolfSSL were only supported in the armv8QNX7.1qcc_gpp8.3.0 target architecture. This release of the Security Plugins introduces support for wolfSSL® 5.5.1 on these platforms when using x64 CPUs:

• Red Hat® Enterprise Linux 8.0 and 9.0
• Ubuntu 18.04 LTS, 20.04 LTS, and 22.04 LTS

The RTI architecture for these platforms is x64Linux4gcc7.3.0.

Please see the instructions in the RTI Security Plugins Installation Guide to get started with the Security Plugins for wolfSSL.

2.1.7.3 Support for Java 17

Starting in this release, RTI's Java® libraries are compiled with AdoptOpenJDK® 17, with backward compatibility with Java 8. The JRE used by RTI Tools (such as Admin Console) is also upgraded to the JRE from OpenJDK™ 17.

2.1.7.4 Support for Java API on macOS 11 and 12 on Arm v8 CPUs

The Java API is now supported when using macOS 11 and 12 architectures on Arm® V8 CPUs (target architecture arm64Darwin20clang12.0).

2.1.7.5 Support for rtiddsgen_server on macOS

RTI Code Generator's rtiddsgen_server is now supported on macOS. Previously, it was supported only on Windows and Linux. This support was added in release 7.1.0, but not documented at that time.

2.1.7.6 New components and imported target libraries for Connext Test Framework added to "FindPackage" CMake script

Connext Test Framework libraries are now installed with the target libraries of each architecture. For details on the Connext Test Framework, which is for use with the Security Plugins SDK, see the RTI Security Plugins Release Notes.

To be able to link against the two new imported targets, two new components have been added to the "Find Package" script (FindRTIConnextDDS.cmake):

• test component:
• RTIConnextDDS::test containing the librtitest library

• test_helpers component:
• RTIConnextDDS::test_helpers containing libnddsctesthelpers and libnddsctransporttesthelpers libraries

2.1.7.7 Future platform changes

This section describes:

• Standard platforms planned for Connext 7.3.0 LTS
• Libraries transitioning from standard to custom support

2.1.7.7.1 Standard platforms planned for Connext 7.3.0 LTS

The following table shows the provisional list of standard libraries that will be supported in Connext 7.3.0 LTS when it is released in 2024. Please note that this table is subject to change; the final version will be published in the Release Notes for Connext 7.3.0 LTS.

Table 2.3 Future Supported Standard Platforms

OS	OS Version	CPU	Toolchain	RTI Architecture
Android ™	Android 12	Arm v8	clang 12.0.8 (ndk r23b)	arm64Android12clang12.0.8ndkr23b
	Android 14	Arm v8	clang (version TBD)	TBD
Linux	Red Hat ® Enterprise Linux 8, 9 Ubuntu 18.04 LTS,, 20.04 LTS, 22.04 LTS	x64	gcc 7.3.0	x64Linux4gcc7.3.0
	Ubuntu 22.04 LTS	x64	clang 15.0.1	x64Linux5clang15.0.1
	Ubuntu 18.04 LTS	Arm v7	gcc 7.5.0	armv7Linux4gcc7.5.0
	Ubuntu 18.04 LTS, 22.04 LTS	Arm v8	gcc 7.3.0	armv8Linux4gcc7.3.0
macOS ®	macOS 11, 12, 13	x64	clang 12.0, 13.0, 14.0	x64Darwin20clang12.0
		Arm v8	clang 12.0, 13.0, 14.0	arm64Darwin20clang12.0
QNX®	QNX Neutrino® 7.1	x64	qcc_cxx 8.3.0 (LLVM C++ library)	x64QNX7.1qcc_cxx8.3.0
		Arm v8	qcc_gpp 8.3.0 (GNU C++ library)	armv8QNX7.1qcc_gpp8.3.0
	QNX Neutrino 8.0	x64	qcc_cxx (version TBD) (LLVM C++ library)	TBD
		Arm v8	qcc_gpp (version TBD) (GNU C++ library)	TBD
VxWorks ®	VxWorks 23.09	x64	llvm (version TBD)	TBD
				TBD (_rtp)
Windows ®	Windows 10, 11, Windows Server 2016, 2022	x64	VS 2017, VS 2019, VS 2022	x64Win64VS2017
	Windows 11	Arm v8	VS 2022	TBD

If you have any questions regarding the differences between a Target Library Standardization (TLS) and a CTL, please consult your sales representative.

2.1.8 Deprecations and Removals

This section describes products, features, and platforms that are deprecated or removed starting in release 7.2.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.

2.1.8.1 RTI Connector for Python removed in this release

Now that the Python API is fully supported, Connector for Python is removed in release 7.2.0. (It was deprecated in 7.0.0.) See 2.1.4 Python API Now Fully Productized and Supported. Connector for Javascript is still supported.

2.1.8.2 Durable Writer History and Durable Reader State properties deprecated in this release

Because of the enhancements described in 2.1.10.4 Durable Writer History and Durable Reader State can now be persisted in SQLite database, this release deprecates the dds.data_writer.history.* and dds.data_reader.state.* properties (except for the dds.data_reader.state.persistence_service.request_depth property). Although these deprecated properties are still available for use, you should use the fields in the DURABILITY QoS policy instead to configure the durable writer history and durable reader state. The deprecated properties may be removed in a future release.

2.1.8.3 OpenSSL 1.1.1 support removed in this release

The support of OpenSSL 1.1.1 has been removed, because it is end-of-life in September, 2023. See also the RTI Security Plugins Release Notes, RTI TLS Support Release Notes, and RTI Web Integration Service Release Notes.

2.1.8.4 Deprecated computed_crc_kind property

The CRC_32_LEGACY option value, used by the computed_crc_kind property, is deprecated starting in release 7.2.0. See 2.1.10.5 Support for RTPS Header Extension for more information.

2.1.9 Product Availability Changes

2.1.9.1 RTI Database Integration Service not included in this release

Database Integration Service is not included in release 7.2.0. You can use Database Integration Service versions 6.1.2 or older. If you use those versions with a Connext 7 release, see the Migration Guide on the RTI Community Portal (https://community.rti.com/documentation); look for the "Wire Protocol" sections to find wire protocol compatibility issues, if any, between the older release and the Connext 7 release. Address these issues before using Database Integration Service with Connext 7.

2.1.10 Other

2.1.10.1 Convert between BuiltinTopicKey and InstanceHandle using new C and Traditional C++ API functions

When using the C or Traditional C++ API, you may sometimes want to convert a BuiltinTopicKey to an InstanceHandle. For example, suppose you call DDS_DataWriter_get_matched_subscription_participant_data to get the DDS_BuiltinTopicKey_t of the DomainParticipant whose DataReader is matched with your DataWriter, and then you want to call DDS_DomainParticipant_ignore_participant on that DomainParticipant. This release introduces the API function DDS_BuiltinTopicKey_to_instance_handle, which allows you to get the InstanceHandle that you can pass into a function such as DDS_DomainParticipant_ignore_participant. For completeness, this release also introduces the API function DDS_BuiltinTopicKey_from_instance_handle to do the opposite conversion.

2.1.10.2 Receive thread behavior is more deterministic and debuggable

Connext relies on a thread pool to service transport receive resources. In previous releases, the threads of this pool were not bound to any specific resource, and therefore any thread could serve any transport receive resource at any time.

This release changes the way the receive threads are managed: receiver threads are now bound to specific transport receive resources. Connext creates a specific thread to serve each resource, and the lifecycle of the thread is tied to the lifecycle of the associated receive resource. As a result of this change, receive thread behavior is more deterministic and debuggable, and it is possible for Connext applications to (subject to the operating system's capabilities) change the thread configuration for specific receive resources.

2.1.10.3 Support for Distributed Logger in Modern C++

Previously, Distributed Logger was only available in C, Traditional C++, and Java. Distributed Logger functionality is now fully supported by the Modern C++ API. The new Distributed Logger API has also been redesigned to be used more intuitively and to follow Modern C++ best-practices. See the RTI Distributed Logger Modern C++ API Reference.

2.1.10.4 Durable Writer History and Durable Reader State can now be persisted in SQLite database

Before Connext 6.1.1, the ability to persist the historical cache of a DataWriter and the state of a DataReader was only supported with external relational databases such as MySQL. In 6.1.1 the support for external databases was deprecated, and support for Durable Writer History and Durable Reader State was temporarily disabled. This release reintroduces these two features by providing file-based storage using an SQLite database.

In addition to allowing persisting the Durable Writer History and Durable Reader State into SQLite files, this release simplifies the configuration of these features by going away from property-based configuration and introducing a new QoS field in the DURABILITY QoS policy, storage_settings. This field can be used for DataWriters and DataReaders. It can be configured programmatically or via XML like any other QoS value. For example, enabling Durable Writer History is as simple as this:

<datawriter_qos>

    <durability>

        <persistent_storage>

            <enable>true</enable>

            <file_name>MyDB.db</file_name>

        </persistent_storage>

    </durability>

</datawriter_qos>

For more information, see Mechanisms for Achieving Information Durability and Persistence, in the RTI Connext Core Libraries User's Manual.

2.1.10.5 Support for RTPS Header Extension

This release adds support for the RTPS Header Extension, defined in the OMG Real-Time Publish-Subscribe (RTPS) specification, version 2.5. The Header Extension is a special submessage that can be added to every RTPS message. It contains metadata about the entire RTPS message, which can be useful for diagnostics and debugging. Introduction of this feature deprecates the rti-specific RTPS CRC and makes the new, RTPS-specification-compliant CRC32C, transported on the RTPS Header Extension, the new default. For details, see information about the compute_crc and check_crc fields in WIRE_PROTOCOL QosPolicy (DDS Extension) in the RTI Connext Core Libraries User's Manual.

2.1.10.6 Variables no longer created for each baseline QoS

Prior to this release, variables were created for each new baseline QoS: for example, DDS_PROFILE_BASELINE_7_1_0 for the 7.1.0 release. For this and future releases, these variables will no longer be created due to their limited usefulness.