3. What’s New in 7.7.0
This section describes what’s new in the Core Libraries compared to release 7.6.0 (see Previous Releases).
RTI® Connext® 7.7.0 is the first production release in the 7.7 long-term support (LTS) series. It is built upon and combines all of the features in releases 7.4.0, 7.5.0, and 7.6.0. 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.7.0 and previous releases, see the Migration Guide on the RTI Community Portal.
3.1. Discovery
3.1.1. Reduce network traffic and system startup time by sending full type information only when needed
Connext now provides support for the OMG Extensible Types TypeLookup Service and TypeObject v2 wire representation, as defined by the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.4. This feature addresses discovery scalability problems common in large-scale and evolving systems by fundamentally changing how data types are shared across a network.
Previously, Connext propagated full type definitions (TypeObject v1) from every endpoint to every application during the discovery process. In systems with hundreds of nodes or complex types, this resulted in massive redundant wire traffic and slow discovery times.
The new TypeLookup Service introduces a more intelligent, request-reply mechanism for type propagation, providing on-demand type discovery. Instead of blindly sending full type definitions, endpoints now send a unique TypeIdentifier (hash) during initial discovery. As a result, type information is sent only a single time when needed.
Hash-Based Identification: Participants use these hashes to check for local compatibility without needing the full type description.
On-Demand Retrieval: If a participant discovers an unknown hash, it uses a dedicated, reliable builtin channel to request the specific TypeObject v2 definition only once.
Efficient Propagation: Once a type is retrieved, it is cached locally, ensuring that the same definition is never sent more than once to any single participant.
Key benefits:
Reduced Network Traffic: Greatly minimizes the amount of data sent during discovery, particularly in large systems where the same type is reused across many endpoints.
Faster System Startup: Improves discovery completion time, allowing applications to reach a “ready” state much more quickly.
Richer Type Metadata: TypeObject v2 is more expressive than its predecessor, allowing the propagation of previously unsupported information such as member ranges (@min, @max) and default values (@default).
Vendor Interoperability: Enhances out-of-the-box compatibility with other DDS implementations that rely on the standard TypeLookup Service to resolve type dependencies.
The TypeLookup Service and TypeObject v2 are enabled by default in
this release. To maintain compatibility with older Connext versions
(which use TypeObject v1), newer applications can be configured to send
both v1 and v2 representations simultaneously or just TypeObject v1.
Additionally, customers who previously disabled type propagation
entirely (by setting type_object_max_serialized_size to 0) can
continue to do so with no performance regressions.
See Type Lookup Service in the RTI Connext Core Libraries User’s Manual for more information.
3.1.2. type_object_max_serialized_length defaults to LENGTH_AUTO, in support of new TypeObject v2 default
Both type_object_max_serialized_length and
serialized_type_object_dynamic_allocation_threshold now have default
values of LENGTH_AUTO. LENGTH_AUTO disables the propagation of
TypeObject v1, in favor of the new default, TypeObject2. (LENGTH_AUTO
effectively translates to 0 internally for both
type_object_max_serialized_length and
serialized_type_object_dynamic_allocation_threshold.)
See the RTI Connext Core Libraries Extensible Types Guide for more information.
3.1.3. LBED Plugin now supports setting DataRepresentationQosPolicy
The RTI Limited Bandwidth Endpoint Discovery (LBED) Plugin now supports the DataRepresentation QoS policy when asserting remote endpoints. Previously, if the DataRepresentation QoS policy was set in the LBED XML configuration, its value was ignored and the default value was assumed for all remote endpoints. This meant that if the value for local endpoints was set to something that was not compatible with the default value, discovery would fail due to incompatible QoS.
For a full list of the supported QoS Policies, see 4.3 Supported QoS in the RTI LBED Plugin User’s Manual.
3.2. Performance and Scalability
3.2.1. Significant memory footprint reduction for Connext applications
Release 7.7.0 delivers substantial memory savings for Connext applications, reducing usage for large-scale systems between 15% to 40% based on certain QoS settings and application size.
These optimizations are organized into two areas:
General improvements that benefit all Connext applications, regardless of which features are in use.
Feature-specific improvements that lower memory usage based on the application’s configuration:
Applications leveraging the Security Plugins will see a reduction in overall memory consumption.
When a reliable DataWriter is matched exclusively with reliable DataReaders, setting
writer_qos.reliable.exact_reliability_kind_matchto true (see here) avoids allocating unnecessary resources on the DataWriter side.DataReaders configured to filter redundant samples (the default) now consume less memory.
Memory usage on the DataReader side is automatically reduced when the Request/Reply pattern or Application-Level Acknowledgments are not in use.
Beyond the lazy allocation introduced by the new QoS field
reader_qos.reader_resource_limits.lazily_allocate_batch_resources(see here), overall memory consumption for batching on the DataReader side has been optimized.
These changes are especially valuable for large distributed systems where many participants and endpoints drive rapid memory growth, for edge and embedded platforms (such as robotics, medical devices, and autonomous systems) that operate under tight memory constraints, and for cloud or virtualized environments where a smaller footprint directly translates to cost savings and higher workload density.
See also RTI Connext Performance Benchmarks.
3.2.2. Reduced default metrics set in Monitoring Library 2.0, minimizing bandwidth utilization
When a Collector Service is active, Monitoring Library 2.0 now reduces the default set of published metrics to minimize bandwidth utilization.
The default metrics focus on those required to drive alerts in the standard Grafana Observability dashboards. Additional metrics can be enabled on demand from the Grafana UI by sending a command to the Collector Service.
To see which metrics are enabled by default, refer to Setting Initial Metrics and Log Configuration in the RTI Connext Observability Framework User’s Manual.
To restore the previous behavior and publish all available metrics, update the Monitoring Library 2.0 configuration as follows:
<qos_library name="MyQosLibrary">
<qos_profile name="MyApplicationProfile" is_default_participant_factory_profile="true">
<participant_factory_qos>
<monitoring>
<!-- Enable monitoring -->
<enable>true</enable>
<!-- Enable all metrics -->
<telemetry_data>
<metrics>
<element>
<resource_selection>//*</resource_selection>
<enabled_metrics_selection>
<element>*</element>
</enabled_metrics_selection>
</element>
</metrics>
</telemetry_data>
</monitoring>
</participant_factory_qos>
</qos_profile>
</qos_library>
See Monitoring Library 2.0 in the RTI Observability Framework User’s Manual for more information.
3.2.3. Improved discovery and reduced overhead with Collector Service
Default discovery and liveliness settings for Collector Service and Monitoring Library 2.0 participants have been updated to improve responsiveness.
Because observability discovery is asymmetric (applications discover Collector Service), late-joining Collector Services could previously take up to 30 seconds to be discovered. This is now improved.
The new defaults provide faster discovery and quicker detection of Collector Service loss:
participant_liveliness_lease_duration= 35sparticipant_liveliness_assert_period= 10smax_liveliness_loss_detection_period= 10s
In addition, bandwidth has been reduced by disabling unnecessary system properties.
Several system properties that increase DATA(P) size are now disabled by default, reducing bandwidth and memory usage. This disabled properties are as follows:
dds.sys_info.creation_timestampdds.sys_info.executable_filepathdds.sys_info.execution_timestampdds.sys_info.targetdds.sys_info.username
Finally, the initial discovery announcements on LAN
(<initial_participant_announcements>) have decreased from 5 to 3.
Lowering the number of initial participant announcements reduces
discovery traffic to the Monitoring Library 2.0 initial peers.
All these changes are part of the Generic.Monitoring2 builtin
profile. See Configuring QoS for Entities
in the RTI Observability Framework User’s Manual for more information.
3.2.4. Improved write execution time when dds.data_writer.history.purge_samples_after_acknowledgment set to 1
This release improves the DataWriter write() execution time and
CPU usage in the following scenario:
The DataWriter enables durable writer history.
The DataWriter is configured with Required Subscriptions.
The DataWriter is configured with dds.data_writer.history.purge_samples_after_acknowledgment set to 1.
The performance improvement is in the writing of live data and is more noticeable when there are many historical samples in the DataWriter queue that are being delivered and acknowledged while the DataWriter is writing live data.
3.2.5. Durable Writer History performance improvements when application-level acknowledgments enabled
This release may improve the performance of Durable Writer History when
application-level acknowledgments are enabled in the DataWriter (by
setting reliability.acknowledgment_kind to
APPLICATION_AUTO_ACKNOWLEDGMENT_MODE or
APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE) and when the DataWriter
does not set the on_application_acknowledgment callback in the
DataWriterListener.
See Notification of Delivery with Application Acknowledgment for more information.
3.2.6. Priority inheritance used when creating semaphores in Linux
Starting with this release, mutexes are created with priority
inheritance on Linux platforms that support it. Now, if
ThreadSettingsKind::REALTIME_PRIORITY is used, there is no risk of
priority inversion where a high-priority thread is being indirectly
blocked by a lower-spriority thread.
See Using REALTIME_PRIORITY in the RTI Connext Core Libraries Platform Notes.
3.2.7. Improved responsiveness to remote reader configuration updates
Updates to remote DataReader configurations (for example,
ContentFilteredTopic changes) are applied more promptly now, making
DataWriter::get_matched_subscription_data less likely to block while
waiting for those changes to take effect.
3.2.8. Performance improvement loading XML QoS profiles
This release introduces a performance improvement for loading user-defined and builtin XML QoS profiles, particularly in environments with file-system contention or slow I/O. Previously, the process of loading profiles could trigger repeated file-system lookups for the NDDS_DISCOVERY_PEERS file—even when the file did not exist—resulting in unnecessary overhead. With this change, the existence of the NDDS_DISCOVERY_PEERS file is checked only once and the result is cached, significantly reducing redundant file-system operations during profile loading. This enhancement may lead to noticeable performance gains during operations such as setting the DomainParticipantFactory QoS or creating a DomainParticipant.
3.2.9. Improved performance of Dynamic Data-to-text format functions
The performance of the DDS_DynamicDataFormatter_to_***() functions
used to convert from a Dynamic Data object into a text-based format has
been greatly improved.
3.2.10. DomainParticipants rejoin the system faster
Discovery in asymmetric liveliness loss scenarios has been sped up by sending late-joiner heartbeats immediately in response to late joining (or rejoining) participants. Previously, the response was delayed by the late_joiner_heartbeat_period (3s by default), slowing down the return of communication.
3.2.11. Disable reliable writer communication with best effort reader to improve performance and memory usage
Reliable DataWriters may send data to both Best Effort and Reliable DataReaders. The Reliability QoS property exact_reliability_kind_match has been added to avoid Reliable DataWriters matching with Best Effort DataReaders. Set this QoS property to true in the DataWriter to save memory and CPU cycles if communication with Best Effort DataReaders is not required.
See the reliability properties to know when a DataReader and a DataWriter will match when the QoS property exact_reliability_kind_match is set to true or false.
3.2.12. Improve performance of durable DataWriters when sending data to late-joining DataReaders, using new property
A new property has been added,
dds.data_writer.history.odbc_plugin.read_batch, which defines how
many DDS samples will be pre-fetched from the database to satisfy
requests from late-joiners by a DataWriter that is configured with
durable writer history.
Lowering this value may help reduce temporary initial memory allocations when connecting to a late-joining DataReader when there are a large number of samples in the database.
When a DataReader requests DDS samples from a DataWriter by sending a NACK message, the DataWriter may retrieve additional DDS samples from the database to minimize disk access.
See the Property Reference Guide for information about the property. See also How To Configure Durable Writer History in the RTI Connext Core Libraries User’s Manual.
3.3. APIs
3.3.1. New resource limit gives more control over memory allocation
Previous releases already had the following resource limit QoS settings:
This release completes the configuration by adding DataWriterResourceLimitsQos::initial_remote_readers. Now, you have more control over how much memory to pre-allocate vs. dynamically allocate for the remote readers matched with a given DataWriter.
3.3.2. New APIs allow your application code to check for type assignability issues
Connext checks by default whether two topic-types are structurally compatible (assignable) in order to decide if a DataWriter and DataReader with different types can communicate. See Verifying Type Consistency: Type Assignability.
This release exposes this functionality in the API so you can now check whether two types are assignable in your application code. For example, you could write custom monitoring utilities that programmatically compare publication and subscription types to detect type compatibility issues.
The newly added APIs are as follows:
C
DDS_Boolean DDS_TypeCode_is_assignable_from(
const DDS_TypeCode *self,
const DDS_TypeCode *from,
DDS_ExceptionCode_t *ex
)
Traditional C++
DDS_Boolean DDS_TypeCode::is_assignable_from(
const DDS_TypeCode *from,
DDS_ExceptionCode_t& ex
) const
Modern C++
bool dds::core::xtypes::DynamicType::is_assignable_from(
const DynamicType& from
) const
C#
public bool DynamicType.IsAssignableFrom(DynamicType from)
Python
DynamicType.is_assignable_from(from_type: DynamicType) -> bool
Note: the Java API already provided boolean TypeCode.assignable(TypeCode other).
3.3.3. Option to lazily allocate batching resources in DataReaders, reducing unnecessary memory usage
Previously, DataReaders allocated resources for batch management up front. This resulted in unnecessary memory usage if the DataReader never matched with a DataWriter that had batching enabled.
To address this, DataReaders now default to lazy allocation, meaning
memory is allocated from the heap only upon receiving the first batch of
samples. While this significantly reduces memory consumption for
non-batched use cases, it may introduce slight latency when the first
batch is received. If you require deterministic performance and prefer
to allocate all resources up front, you can set
DataReaderResourceLimitsQos::lazily_allocate_batch_resources to
FALSE.
See DATA_READER_RESOURCE_LIMITS QosPolicy in the RTI Connext Core Libraries User’s Manual.
3.3.4. Python API supports versions 3.10 to 3.14, no longer supports versions 3.8 and 3.9
This release adds support for the Connext Python API on Python 3.13 and 3.14. The Python API now runs on versions 3.10 to 3.14. Python 3.8 and 3.9 are no longer supported.
3.4. Usability
3.4.1. Monotonic clock as new default enhances robustness against system clock changes
To enhance robustness against system clock changes, the internal clock now defaults to a monotonic clock on all platforms that support it, rather than to a realtime clock. It defaults to realtime if the platform does not support a monotonic clock. This change helps prevent issues related to adjustments in the system time. See Configuring the Clock per DomainParticipant in the Core Libraries User’s Manual for more information.
3.4.2. Increased maximum length of command-line parameters for rtiddsspy
The maximum length of the command-line parameters for rtiddsspy was limited to 512 bytes. Now the limit is 1024 bytes.
3.4.3. Built-in QoS Snippets added to easily enable or disable TypeObject v1 and TypeObject v2
The following Built-in QoS Snippets were added, to allow you to easily enable or disable TypeObject v1 and TypeObject v2 via XML:
BuiltinQosLib::Feature.TypeSupport.V1.Enable: Enables TypeObject v1 propagation.
BuiltinQosLib::Feature.TypeSupport.V1.Disable: Disables TypeObject v1 propagation.
BuiltinQosLib::Feature.TypeSupport.V2.Enable: Enables TypeObject v2 propagation.
BuiltinQosLib::Feature.TypeSupport.V2.Disable: Disables TypeObject v2 propagation.
See Reduce network traffic and system startup time by sending full type information only when needed for more context. See QoS Profile Inheritance and Composition for information on Snippets.
3.4.4. Flexible control over Monitoring Library 2.0 enablement using new environment variable
A new environment variable, RTI_MONITORING2_ENABLE, can now be set
to 1, true, or on (case insensitive) to enable Monitoring Library
2.0. The variable can be set to 0, false, or off to disable it.
The RTI_MONITORING2_ENABLE setting takes precedence over the XML
configuration.
See Enabling Monitoring Library 2.0 in the RTI Connext Observability Framework User’s Manual for more information.
3.5. Debuggability
3.5.1. Monitoring Library 2.0 now enabled by default under specific conditions, making it easier to use remote debugging
Monitoring Library 2.0 is now enabled by default for Connext applications if either of the following conditions is met:
Your application links to dynamic Connext libraries and Monitoring Library 2.0 is available in your library path.
Your application links to static Connext libraries (including Monitoring Library 2.0) and you invoke
RTI_Monitoring_initialize.
This improvement enables you to use the Observability Framework and Admin Console Remote Debugging feature at any time without modifying your deployed applications. All Connext Infrastructure Services (except Collector Service) also enable the library by default when available in the library path. The library remains disabled by default in RTI Admin Console, RTI Monitor, RTI DDS Spy, and RTI DDS Ping.
See Enabling Monitoring Library 2.0 in the Observability Framework documentation for more information.
3.5.2. Monitoring Library 2.0 security enforced when using an RTI security plugin, elevating security standards
To prevent Monitoring Library 2.0 from inadvertently publishing telemetry data and metrics from a secured application over an unsecured channel, Connext now enforces that Monitoring Library 2.0 is also secured whenever any DomainParticipant in the application uses a security plugin (either the RTI Security Plugins or the Lightweight Security Plugins).
If any DomainParticipant in your application has security enabled and Monitoring Library 2.0 is not secured, the enablement of Monitoring Library 2.0 will fail with the following error:
[ERROR] FAILED TO ENABLE | You are attempting to enable the RTI Monitoring Library 2.0 without security, but your system already contains a DomainParticipant with security enabled. Please, enable security for the RTI Monitoring Library 2.0 (refer to the RTI Connext Observability Framework for further information).
Conversely, if Monitoring Library 2.0 is already enabled without security, enabling a DomainParticipant that uses a security plugin will fail with the following error:
[ERROR] FAILED TO ENABLE | You are attempting to enable a secure DomainParticipant, but the RTI Monitoring Library 2.0 is not secured. Please, disable RTI Monitoring Library 2.0 (using factoryQos.monitoring.enable) or enable security for it (refer to the RTI Connext Observability Framework for further information).
To resolve either error, enable security for Monitoring Library 2.0 by
configuring the appropriate security artifacts in the monitoring
DomainParticipant QoS profile, or disable Monitoring Library 2.0
using participant_factory_qos.monitoring.enable.
For details on how to secure Monitoring Library 2.0, see the Security chapter in the RTI Connext Observability Framework User’s Manual.
3.5.3. Improved diagnostics through extended SQLite error codes in durable writer and reader state databases
Errors detected in SQLite database files used for durable writer history and durable reader state now include SQLite extended error codes. This additional information improves diagnostics and helps identify the underlying cause of database-related issues.
3.5.4. Debug symbols for release libraries now provided for Linux platforms
On Linux platforms, debug symbols for the release libraries are now also provided as an alternative to the debug libraries, allowing source-level debugging without the performance overhead of the debug libraries. See Debug Symbols for Release Dynamic Libraries in the RTI Connext Core Libraries Platform Notes for more information.
3.6. OMG Specification Compliance
3.6.1. Better control communication in a system with changing types and evolving data model requirements, using @must_understand annotation
Connext now lets you mark members of a struct as “Must-Understand” to make sure that they will be present in both types of two matched endpoints.
In most cases, struct types that are extended with additional members will remain “assignable” to their base versions, which allows DataWriters and DataReaders that use different versions of a type to still match and exchange data.
During the evaluation of a potential match between a DataWriter and a DataReader, any member marked as Must-Understand that doesn’t appear in the other side’s type will cause the two endpoints to have “unassignable” types, and the match to fail.
When using @mutable types, Must-Understand members that are also marked Optional will not affect matching, but any sample containing them will be dropped by any DataReader whose type doesn’t declare them.
See Must-Understand Members in the RTI Connext Core Libraries Extensible Types Guide for more information.
3.6.2. Augment your data models by explicitly describing units of measurement associated with types
You can now quantify your data with the @unit annotation, to
explicitly describe units of measurement associated with your types. The
@unit annotation can be used on aliases of any type, and on any
member of a struct or union. The annotation accepts an arbitrary string
value, without enforcing any specific syntax.
The annotated value can be retrieved at runtime by inspecting the generated type descriptors, and it will be propagated through discovery for access from remote nodes.
See Units in the RTI Connext Core Libraries Extensible Types Guide for more information.
3.7. DDS Spy
3.7.1. Improved transport configuration in DDS Spy with alias-based option
RTI DDS Spy now supports configuring built-in transports using
human-readable aliases (e.g., shmem|udpv4) instead of decimal
bitmasks. This enhancement makes it easier to enable and combine
UDPv4, UDPv6, and shared memory transports when using the
-transport option.
See Usage in the RTI DDS Spy User’s Manual for more information.
3.7.2. Support for Real-Time WAN Transport in DDS Spy
This release adds support to DDS Spy for the RTI Real-Time WAN
Transport. When using udpv4_wan with the -transport option, you
must always provide a Real-Time WAN Transport peer using the -peer
option.
Example:
rtiddsspy -transport udpv4_wan -peer udpv4_wan://10.10.10.1:1234
See Usage in the RTI DDS Spy User’s Manual for more information.
3.7.3. Support for participant discovery events in DDS Spy
This release introduces support for participant discovery events in DDS Spy (rtiddsspy). The utility now reports when participants are discovered, updated, or deleted.
Example output:
RTI Connext DDS Spy built with DDS version: 7.7.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
rtiddsspy is listening for data, press CTRL+C to stop it.
16:48:51 New participant from 10.30.2.67 : guid="0x010167FB,0xE44F34EB,0xB6EF158B:0x000001C1" name="Shapes Role:RTI Shapes Demo" partition="PartA,PartB" processId="12234"
16:48:51 Updated participant from 10.30.2.67 : guid="0x010167FB,0xE44F34EB,0xB6EF158B:0x000001C1" name="Shapes Role:RTI Shapes Demo" partition="PartA,PartB" processId="12234"
16:48:54 New writer from 10.30.2.67 : topic="Square" type="ShapeType" guid="0x010167FB,0xE44F34EB,0xB6EF158B:0x80000002" publisherObjectId="0x00000108" name="RTI Shapes Demo" DP partition="PartA,PartB" P partition="Part1"
17:46:46 Deleted writer from 10.30.2.67 : topic="Square" type="ShapeType" guid="0x010167FB,0xE44F34EB,0xB6EF158B:0x80000002" publisherObjectId="0x00000108" name="RTI Shapes Demo" DP partition="PartA,PartB" P partition="Part1"
17:46:48 Deleted participant from 10.30.2.67 : guid="0x010167FB,0xE44F34EB,0xB6EF158B:0x000001C1" name="Shapes Role:RTI Shapes Demo" partition="PartA,PartB" processId="1234"
See Understanding the Output in the RTI DDS Spy User’s Manual for more information.
3.7.4. DDS Spy option for printing Publisher and Subscriber Object IDs for easier diagnostics
This release introduces an improvement that, when the existing
command-line option -showHandle is used in rtiddsspy, prints the
Object ID of the Publisher and Subscriber associated with a
discovered entity (DataWriter or DataReader), in addition to the
entity GUID. This capability enhances traceability, making it easier to
analyze and troubleshoot your applications.
For example:
16:39:01 New writer from 192.168.1.213 : topic="Square" type="ShapeType" guid="0x0101850C,0x604B1633,0x2129819D:0x80000002" publisherObjectId="0x00000108" name="RTI Shapes Demo"
In this example, the Publisher GUID shares the prefix with the entity
GUID and differs only in the Object ID:
0x0101850C,0x604B1633,0x2129819D:0x00000108.
See Usage in the RTI DDS Spy User’s Manual for more information.
3.7.5. New DDS Spy option for QoS inspection to help identify incompatibilities that prevent communication
This release introduces a new command-line option, -showEntityQos,
for DDS Spy (rtiddsspy) that allows you to inspect the QoS policy
values used for matching in discovered entities. Being able to inspect
QoS values used helps identify incompatibilities that prevent
communication.
The displayed QoS policies include:
Reliability
Durability
Deadline
DestinationOrder
Ownership
DataRepresentation
LatencyBudget
Liveliness
Partition
Presentation
See Usage in the RTI DDS Spy User’s Manual for more information.
3.7.6. New DDS Spy options for type inspection
This release introduces three new command-line options to rtiddsspy that allow you to inspect the type definition and the sample JSON schema of remote endpoints as they are discovered.
-showTypeDefinition: Displays the type definition each time a new remote endpoint with type information is discovered.-typeDefinitionFormat <XML|IDL>: Specifies the format used to display the type definition when-showTypeDefinitionis enabled. The default format isIDL.-showSampleSchema: Displays the sample JSON schema each time a new remote endpoint with type information is discovered.
The generated JSON schema is useful for understanding the structure of
the data samples being received. These samples can be printed in JSON
format using the -printSample COMPACT option.
Note: The generated JSON schema describes the structure of
JSON-encoded data samples for a given type. It is not intended to be a
complete or canonical representation of the corresponding IDL type. To
obtain the full and authoritative IDL definition, use the
-showTypeDefinition option.
See Usage in the RTI DDS Spy User’s Manual for more information.
3.8. Deprecations and Removals
This section describes items that are deprecated or removed in 7.7.0, compared to 7.6.0. See also deprecations and removals in Previous Releases.
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.
3.8.1. Python 3.8 and 3.9 no longer supported
See Python API supports versions 3.10 to 3.14, no longer supports versions 3.8 and 3.9.
3.9. Third-Party Software Changes
The following third-party software used by Connext has been upgraded:
Third-Party Software |
Old Version |
New Version |
|---|---|---|
Expat |
2.7.1 |
2.7.3 |
Apache Log4j 2 |
2.17.1 |
2.25.3 |
The following third-party software is now used by DDS Spy:
Third-Party Software |
Version |
|---|---|
CivetWeb |
1.16 |
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.
3.10. Other
3.10.1. Improved isolation for observability traffic
The configuration of the DomainParticipant created by Monitoring Library 2.0 has been updated to improve traffic isolation.
By default, the DomainParticipant now runs in domain 101, which is
less commonly used than the previous default domain (2), reducing
the likelihood of unintended interference with application traffic.
Additionally, the DomainParticipant is assigned the domain tag
RTI_o11y, providing an extra layer of isolation for
observability-related communication.
For more information, see Monitoring Library 2.0 in the RTI Connext Observability Framework User’s Manual.
3.10.2. Aliases for enabled_transport QoS no longer require case-sensitive matching
The enabled_transport QoS required exact case matches for transport
aliases. This issue has been resolved by making alias matching
case-insensitive, allowing enabled_transport values to be accepted
regardless of letter case.
3.10.3. Disallow unrealistic values of polling_period, to avoid errors collecting data for Observability Framework
Monitoring Library 2.0 uses the
DDS_MonitoringPeriodicDistributionSettings::polling_period
to periodically poll for new telemetry data to send to RTI
Observability Framework. To avoid internal integer overflows, the
polling_period must now be no more than 4294967 seconds (50 days).
Enabling Monitoring Library 2.0 will no longer succeed if the
polling_period exceeds this value.
3.10.4. Allow disabling signal-blocking on Connext Threads for POSIX platforms
Historically, Connext has blocked signal handling in threads it creates and manages, for most signals and for POSIX platforms. This was done to ensure that the system is robust to unexpected signal handlers—for example, when a mutex is held.
To ensure that Connext can be used on platforms that rely on signal
handling (for example, the Unity platform, whose GC (garbage collection)
management relies on signal handling), it’s now possible to disable
signal-blocking by setting the environment variable
NDDS_DISABLE_SIGNAL_BLOCKING to any value.
3.10.5. Convert DynamicType (or TypeCode) to JSON schema, for enhanced interoperability
This release adds an option to convert a DynamicType (or TypeCode) into a JSON schema. The generated JSON schema describes the structure of JSON data samples for a given type. This capability can be useful for sharing your data model with systems or tools that do not use DDS.
This option is supported in the following languages:
C
Traditional C++
Modern C++
In C and traditional C++, a new value has been added to the
DDS_TypeCodePrintFormatKind enumeration:
DDS_TYPE_CODE_PRINT_KIND_JSON_SCHEMA
This output format can be used with the print and to_string APIs
of DDS_TypeCode.
In modern C++, a new value has been added to the
DynamicTypePrintKind enumeration:
json_schema
This output format can be used with the rti::core::xtypes::to_string
API.
See the DDS Consolidated JSON Syntax for more information.
3.10.6. Ensure compatibility with other DDS vendors using updated Compatibility.OtherDDSVendor.Enable QoS snippet
The Compatibility.OtherDDSVendor.Enable QoS Snippet has been modified to enable TypeObject v2 and disable the sending of TypeObject v1. This change ensures compatibility with systems that use TypeObject v2 (originally defined in the XTypes specification version 1.2) as the wire representation for types. By default, the receipt of TypeObject v1 information is still enabled, so applications using this snippet will still accept TypeObject v1 from applications that are not yet supporting TypeObject v2.
Additionally, this snippet now disables compression of TypeObject v1. Although the snippet does not send TypeObject v1, if you were to use the snippet and then explicitly enable TypeObject v1 in the same application (via modifying the QoS after the snippet was applied), the TypeObject v1 is no longer compressed. This change improves interoperability with vendors who don’t support decompression.
See TypeLookup Service in the RTI Connext Core Libraries User’s Manual for more information on TypeObject v1 and TypeObject v2. See QoS Profile Inheritance and Composition for more information on Snippets.
3.10.7. Added operation to retrieve remaining time until license expiration
A new operation has been added to the C and Modern C++ API’s to get the remaining time (in seconds) until a license expires. This operation is only available in license-managed distributions. See Using an Activation Library in the RTI Connext Installation Guide for details.