7.1. Supported Platforms and Programming Languages

Connext DDS Micro supports the C and traditional C++ language bindings.

Connext DDS Micro is available as pre-built binaries for the following platforms:

Note that RTI only tests on a subset of the possible combinations of OSs and CPUs. Please refer to the following tables for a list of specific platforms and the specific configurations that are tested by RTI.

Table 7.1 Supported Linux Platforms
OS CPU Compiler RTI Architecture Abbreviation
Red Hat® Enterprise Linux® 6.0, 6.1 (2.6 kernel) x86 gcc 4.4.5 i86Linux2.6gcc4.4.5
Table 7.2 Supported Windows Platforms
OS CPU Compiler RTI Architecture Abbreviation
Windows® 7 x86 Visual Studio® 2010 i86Win32VS2010
Table 7.3 Supported VxWorks Platforms
OS CPU Compiler RTI Architecture Abbreviation
VxWorks® 6.9 Pentium® 32-bit gcc 4.3.3 For Kernel Modules: pentiumVx6.9gcc4.3.3
For Real Time Processes: pentiumVx6.9gcc4.3.3_rtp
VxWorks 6.9 PPC32 gcc 4.3.3 For Kernel Modules: ppc604Vx6.9gcc4.3.3
For Real Time Processes: ppc604Vx6.9gcc4.3.3_rtp
VxWorks Cert 6.6.4.1 PPC32 e500v2 gcc 4.1.2 ppce500v2VxCert6.6.4.1gcc4.1.2

7.2. Compatibility

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

7.3. What’s New in 3.0.1

7.3.1. Support for FreeRTOS and ThreadX

This release includes support for the FreeRTOS™ and ThreadX® operating systems.

7.3.2. New QoS parameter to adjust preemptive ACKNACK period

A new QoS parameter has been introduced to expose the preemptive ACKNACK period on DataReaders. The new parameter is configured with:

  • DDS_DataReaderQos.protocol.rtps_reliable_reader.nack_period for user DataReaders
  • builtin_endpoint_reader_nack_period for the builtin discovery endpoints in the Dynamic discovery plugin.

Please see the reference API for details.

7.3.3. Deserialization of Presentation QoS policy

This release provides better support for the Presentation QoS policy. Previously this QoS policy was not supported by the DataWriter; the default value was assumed for a discovered DataReader, which caused an “Unknown QoS” warning when the it was received. In this release, DataWriters will deserialize the Presentation QoS policy and check for compatibility.

7.3.4. Dynamic memory allocations removed from Dynamic Discovery Plugin

The dynamic discovery plugin in Connext DDS Micro allocated memory dynamically after the DomainParticipant was enabled to store discovered type and topic names. This release includes improvements which make it possible to avoid all memory allocations.

Dynamic memory allocations are avoided by creating the DomainParticpiant in a disabled state and creating all local endpoints before the DomainParticipant is enabled.

A DomainParticipant is created in a disabled state by setting DomainParticipantFactoryQos.entity_factory.autoenable_created_entities = DDS_BOOLEAN_TRUE before calling create_participant(). When all entities have been created, call enable() on the DomainParticipantFactory to enable all entities.

7.3.5. New APIs to serialize and deserialize samples

Two new APIs are available to applications to serialize and deserialize samples, for example for record and replay type applications. Please see the C and C++ API reference manuals under “DDS API->Topic->User Data Type Support” for a details.

7.3.6. New QoS parameter to set max outstanding samples allowed for remote DataWriter

A new QoS parameter has been exposed for the endpoint discovery endpoints in the dynamic endpoint discovery plugin (DPDE). You can set the new field, max_samples_per_remote_builtin_endpoint_writer in DPDE_DiscoveryPluginProperty, to increase the number of samples a remote writer may have per builtin endpoint reader and thus decrease network traffic. Please refer to the DPDE reference manual for a description of this new parameter.

7.3.7. DomainParticipants no longer allocate dynamic memory during deletion

DomainParticipants will no longer allocate dynamic memory during deletion.

7.4. What’s Fixed in 3.0.1

7.4.1. DomainParticipant creation failed if active interface had invalid IP

An active interface without a valid IP address assigned may have caused DomainParticipant creation to fail. This problem has been resolved. Now if an interface with an invalid IP address is used, it will be ignored and the DomainParticipant will still be created.

[RTI Issue ID MICRO-1602]

7.4.2. Incorrect C++ example publisher generated for certain annotations

Incorrect C++ example publisher generated for certain annotations

Generating a C++ example for a type annotated with @transfer_mode(SHMEM_REF) and @language_binding(FLAT_DATA) caused the publisher to run out of available loanable samples to publish. This problem has been resolved.

[RTI Issue ID MICRO-1998]

7.4.3. Liveliness lease duration matching did not follow OMG specification

Connext DDS Micro allowed a Writer to match with a remote Reader if the requested Liveliness lease duration was INFINITE, ignoring the Liveliness kind. This behavior did not follow the OMG specification. Now matching will only occur if both these conditions are true:

  • Requested Liveliness lease duration is >= the Offered lease duration.
  • Requested Liveliness kind is <= the Offered Liveliness kind, where AUTOMATIC_LIVELINESS_KIND < MANUAL_BY_PARTICIPANT_LIVELINESS_KIND < MANUAL_BY_TOPIC_LIVELINESS_KIND.

[RTI Issue ID MICRO-2007]

7.4.4. rtime-make did not work when started from different shell than Bash

rtime-make requires Bash on UNIX systems. However it did not explicitly launch Bash and would fail if started from a Bash-incompatible shell. The script now always launches /bin/bash as the shell.

[RTI Issue ID MICRO-2013]

7.4.5. UDP interface warning using valid interfaces

Connext DDS Micro logged a warning if no new interfaces were added for each address listed in the enabled_transports.

This applied to the enabled_transports field in the DiscoveryQosPolicy and UserTrafficQosPolicy in the DomainParticipantQos, and the DDS_TransportQosPolicy in the DataReaderQos and DataWriterQos.

This problem has been resolved. Now Connext DDS Micro will only log a warning if no new interfaces are added per enabled transport.

[RTI Issue ID MICRO-2018]

7.4.6. Payload encryption did not work when using extensible types

Due to a miscalculation of resources, payload encryption failed when using extensible types. This problem has been resolved.

[RTI Issue ID MICRO-2020]

7.4.7. Duplicate DATA messages sent to multicast in some cases

Duplicate DATA messages were sent to multicast when multiple DataReaders were configured with multicast and unicast receive addresses. This problem has been resolved.

[RTI Issue ID MICRO-2043]

7.4.8. Could not build source with OSAPI_ENABLE_LOG=0

The Connext DDS Micro source was compiled with the -DOSAPI_ENABLE_LOG=0. This problem has been resolved.

[RTI Issue IDs MICRO-2049, MICRO-2048]

7.4.9. Compilation error when inter-participant channel disabled

When disabling the inter-participant channel at compile time, the compiler reported an error. This problem has been resolved.

[RTI Issue ID MICRO-2051]

7.4.10. Seq_copy on a loaned or discontiguous sequence caused incorrect behavior

Calling Fooseq_copy() on a loaned or discontiguous sequence did not work correctly. This problem has been resolved.

[RTI Issue ID MICRO-2053]

7.4.11. Compiler warning with const IDL strings or strings

When declaring a const string or string in IDL, the compiler may have reported a warning. This problem has been resolved.

[RTI Issue ID MICRO-2054]

7.4.12. Warnings in header file due to conversion between RTI_BOOL C type and bool C++ type

When compiling the security source, the compiler may have reported a warning: “Warnings in header file due to conversion between RTI_BOOL C type and bool C++ type. ” This problem has been resolved.

[RTI Issue ID MICRO-2056]

7.4.13. DDS_Subscriber_create_datareader() affected by local_writer_allocation limit

The maximum number of DataReaders that could be created was determined by the DomainParticipant.resource_limits.local_writer_alloation resource limit. This problem has been resolved.

[RTI Issue ID MICRO-2065]

7.4.14. Restarting remote participant when using DPSE caused DDSC_LOG_PARTICIPANT_LOOKUP error

When a remote participant was restarted twice or more when using the static discovery plugin (DPSE), the error message DDSC_LOG_PARTICIPANT_LOOKUP was logged. This problem has been resolved.

[RTI Issue ID MICRO-2088]

7.4.15. ‘Failure to give mutex’ error

In Connext DDS Micro 3.0.0, a subtle race condition may have occurred on multi-core machines. When this happened, an error message about failing to give a mutex would be printed: error code (EC) 44 in module 1 (OSAPI). This problem has been resolved.

[RTI Issue ID MICRO-2095]

7.4.16. DDS_LOG_DR_DESERIALIZE_KEYHASH error

A DDS_LOG_DR_DESERIALIZE_KEYHASH error may have been logged, in particular on Linux systems. This issue has been partially fixed in this release.

However, this error may still be logged if the first sample received for an instance is the dispose sample and the dispose sample does not contain the key fields. This is always the case with Connext DDS Micro and may be the case with Connext DDS Professional, if sending the key fields has been disabled. The error is benign and does not cause any communication failure.

[RTI Issue ID MICRO-2097]

7.4.17. Entity ID generation was not thread-safe

Entity ID generation for DataReaders and DataWriters was not thread-safe and may have lead to duplicate entity IDs. This problem has been resolved.

[RTI Issue ID MICRO-2104]

7.4.18. Fully dropped fragmented sample caused communication to stop with KEEP_ALL on DataWriter

The combination of a HistoryQosPolicy kind of KEEP_ALL and having fragmented samples may have caused communication to stop between a writer and reader if all fragments for a sample were lost. This problem has been resolved.

[RTI Issue ID MICRO-2114]

7.4.19. DDS_WaitSet_wait() returned DDS_RETCODE_ERROR if unblocked with no active conditions

An application that used a combination of polling a DataReader and blocking on a DDS_WaitSet may have caused DDS_WaitSet_wait() to return DDS_RETCODE_ERROR. This happened if the DDS_WaitSet was unblocked by an attached condition, but there were no active conditions. This problem has been resolved.

[RTI Issue ID MICRO-2115]

7.4.20. ALREADY_EXISTS error printed in high-load scenarios

The error code (EC) 23, module 2 (DB) may have been printed if a system was under heavy load and participant lease durations expired. This problem has been resolved.

[RTI Issue ID MICRO-2116]

7.4.21. Publication handle not set in SampleInfo structure when on_before_sample_commit() called

The publication_handle member of the DDS_SampleInfo structure passed to a DataReader’s on_before_sample_commit() function was not set. This problem has been resolved.

[RTI Issue ID MICRO-2121]

7.4.22. Using serialize_data_to_cdr_buffer() with statically allocated buffer gave wrong results

Using serialize_data_to_cdr_buffer with a statically allocated buffer may have caused incorrect results if a re-alignment of the buffer size was required.

Foo_serialize_data_to_cdr_buffer() did not support a buffer that was not aligned to 4. This issue has been resolved.

Note that it is still a requirement that the buffer is aligned to at least 4.

[RTI Issue ID MICRO-2130]

7.4.23. Instance resources exhausted even with DDS_REPLACE_OLDEST_INSTANCE_REPLACEMENT_QOS

Instance resources may have been exhausted on the DataReader even when DDS_REPLACE_OLDEST_INSTANCE_REPLACEMENT_QOS was specified as the instance-replacement policy and the DataReader was configured to support both XCDRv1 and XCDRv2. This problem has been resolved.

[RTI Issue ID MICRO-2140]

7.4.24. UDP Transformation feature did not work in version 3.0.0

The UDP Transformation feature was not updated from Connext DDS Micro 2 to work with Connext DDS Micro 3. This problem has been resolved. Please refer to the HelloWorld_transformations example, as Connext DDS Micro 3 uses a different packet structure than Connext DDS Micro 2.

[RTI Issue ID MICRO-2144]

7.4.25. Flow-controller with insufficient bandwidth may have caused communication failure

A flow-controller configured with less bandwidth than required based on the publication rate may have caused a communication failure when a data writer was configured with KEEP_LAST. This problem has been resolved.

[RTI Issue ID MICRO-2155]

7.5. Previous Releases

7.5.1. What’s New in 3.0.0.1

7.5.1.1. New APIs to Serialize and Deserialize Samples

Two new APIs are available to applications to serialize and deserialize samples, for example for record and replay type applications. Please refer to the C and C++ API reference manuals under “DDS API->Topic->User Data Type Support” for a details.

7.5.1.2. Dynamic Memory allocations removed from the Dynamic Discovery Plugin

In previous versions of Connext DDS Micro the dynamic discovery plugin (DPDE) allocates memory after the DomainParticipant is enabled to store discovered Topic and Type names. This release includes improvements which make it possible to avoid all memory allocations after the DomainParticipant is enabled.

When a DomainParticipant discovers a Topic that exists locally no memory is allocated. However, if a Topic is discovered that does not exist locally memory is allocated to store the Topic and Type names.

In order to avoid all dynamic memory allocations during discovery the following rules must be followed:

  • Create the DomainParticipant disabled by setting DomainParticipantFactoryQos.entity_factory.autoenable_created_entities = DDS_BOOLEAN_FALSE before calling create_participant().
  • Create all local DataReaders and DataWriters for all Topics that will be discovered.
  • If it is possible to discover DomainParticipants that will not match with local DataReaders and DataWriters, set DomainParticipantFactoryQos.discovery.accept_unknown_peers = DDS_BOOLEAN_FALSE and list all DomainParticipants that should be discovered in DomainParticipantFactoryQos.discovery.initial_peers.
  • Call enable() on the DomainParticipant to enable all entities.

A known limitation is that it is not possible ignore specific Topics.

7.5.2. What’s Fixed in 3.0.0.1

7.5.2.1. Cannot build source with OSAPI_ENABLE_LOG=0

The Connext DDS Micro source did not compile when logging was disabled with the preprocessor definition -DOSAPI_ENABLE_LOG=0. This has been fixed.

[RTI Issue ID MICRO-2049], [RTI Issue ID MICRO-2048]

7.5.2.2. DDS_Subscriber_create_datareader() was affected by the local_writer_allocation limit

The maximum number of DataReaders that could be created was determined by the DomainParticipant.resource_limits.local_writer_alloation resource limit. This issue has been fixed.

[RTI Issue ID MICRO-2065]

7.5.3. What’s New in 3.0.0

7.5.3.1. Support for XCDR encoding version 2

This release adds support for the standard XCDR encoding version 2 data representation described in the “Extensible and Dynamic Topic Types for DDS” specification. This encoding version is more efficient in terms of bandwidth than XCDR encoding version 1, which is supported in previous Connext DDS releases (and still supported in this release).

To select between XCDR and XCDR2 data representations, you can use the DataRepresentationQosPolicy for DataReaders and DataWriters. Connext DDS Micro now supports this policy. You may specify XCDR, XCDR2, or AUTO to indicate which versions of the Extended Common Data Representation (CDR) are offered and requested. The default is AUTO.

A DataWriter offers a single representation, which indicates the CDR version the DataWriter uses to serialize its data. A DataReader requests one or more representations, which indicate the CDR versions the DataReader accepts. If a DataWriter’s offered representation is contained within a reader’s sequence of requested representations, then the offer satisfies the request, and the policies are compatible. Otherwise, they are incompatible. In support of this feature, a new QoS, DATA_REPRESENTATION, has been added for the DataWriter and DataReader. There is also a new annotation, @allowed_data_representation, that can be used to select the supported data representations for a type.

For more information, see:
  • the “Extensible and Dynamic Topic Types for DDS” specification from the Object Management Group (OMG): https://www.omg.org/spec/DDS-XTypes/.
  • the section on the DATA_REPRESENTATION QoS Policy, in the RTI Connext DDS Core Libraries User’s Manual (available here if you have Internet access).
  • the Data Representation chapter, in the RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types (available here if you have Internet access).

7.5.3.2. Large data streaming using RTI FlatData™ language binding and Zero Copy transfer over shared memory

To meet strict latency requirements, you can reduce the default number of copies made by the middleware when publishing and receiving large samples (on the order of MBs) by using two new features: FlatData language binding and Zero Copy transfer over shared memory.

These features can be used standalone or in combination.

By using the FlatData language binding, you can reduce the number of copies from the default of four copies to two copies, for both UDP and shared memory communications. FlatData is a language binding in which the in-memory representation of a sample matches the wire representation, reducing the cost of serialization/deserialization to zero. You can directly access the serialized data without deserializing it first. To select FlatData as the language binding of a type, annotate it with the new @language_binding(FLAT_DATA) annotation.

Zero Copy transfer over shared memory allows you to reduce the number of copies to zero for communications within the same host. This feature accomplishes zero copies by using the shared memory builtin transport to send references to samples within a shared memory segment owned by the DataWriter, instead of using the shared memory builtin transport to send the serialized sample content by making a copy. With Zero Copy transfer over shared memory, there is no need for the DataWriter to serialize a sample, and there is no need for the DataReader to deserialize an incoming sample since the sample is accessed directly on the shared memory segment created by the DataWriter. The new TransferModeQosPolicy specifies the properties of a Zero Copy DataWriter.

For more information on setting up and using one or both of these features, see the chapter on Sending Large Data, in the RTI Connext DDS Core Libraries User’s Manual (available here if you have Internet access).

7.5.3.3. Support for RTI Security Plugins

RTI Security Plugins introduce a robust set of security capabilities, including authentication, encryption, access control and logging. Secure multicast support enables efficient and scalable distribution of data to many subscribers. Performance is also optimized by fine-grained control over the level of security applied to each data flow, such as whether encryption or just data integrity is required.

Security Plugins are available in a separate package from the RTI Support Portal, https://support.rti.com/.

See the RTI Security Plugins Release Notes and RTI Security Plugins Getting Started Guide (available here and here if you have Internet access).

7.5.3.4. Large Data Types

This release adds support for user-defined data types that exceed the maximum message size supported by the underlying transports, such as 64K in the case of UDP. Its use is fully transparent: samples are automatically fragmented by the DataWriter and reassembled by the DataReader. Once re-assembled, the samples are treated as regular samples and subject to all applicable QoS policies.

7.5.3.5. Asynchronous DataWriters

This release adds support for publishing data asynchronously. An asynchronous DataWriter offloads the user thread and makes it possible to coalesce samples across multiple write() calls into a single network packet.

Samples written by an asynchronous DataWriter are not sent in the context of the user thread as part of the write() call. Instead, samples are queued and sent in the context of a separate, dedicated thread. An optional flow control mechanism is provided to throttle the rate at which samples are coalesced and sent by the dedicated thread.

To implement this feature, there are two new QosPolicies, ASYNCHRONOUS_PUBLISHER and PUBLISH_MODE. The ASYNCHRONOUS_PUBLISHER QosPolicy enables/disables asynchronous publishing for the Publisher. If enabled, the Publisher will spawn a separate asynchronous publishing thread, which will be shared by all of the Publisher’s DataWriters that have their new PUBLISH_MODE QosPolicy set to ASYNCHRONOUS. When data is written asynchronously, a new ‘FlowController’ object can be used to shape the network traffic. The FlowController’s properties determine when the asynchronous publishing thread is allowed to send data and how much.

7.5.3.6. Support for KEEP_ALL History

This release supports setting the History QoS policy kind to KEEP_ALL.

7.5.3.7. Support for AUTOMATIC and MANUAL_BY_PARTICIPANT Liveliness

Now you can set the Liveliness QoS policy kind to AUTOMATIC or MANUAL_BY_PARTICIPANT.

  • AUTOMATIC: Connext DDS Micro will automatically assert liveliness for the DataWriter at least as often as the lease_duration.
  • MANUAL_BY_PARTICIPANT: The DataWriter is assumed to be alive if any Entity within the same DomainParticipant has asserted its liveliness.

7.5.3.8. Micro Application Generation

This release includes Micro Application Generation, which enables you to create a Connext DDS Micro application, including registration of factories and creation of DDS entities, from an XML configuration file. Please see Application Generation in this documentation, as well as the chapter on Generating Applications for Connext DDS Micro, in the RTI Connext DDS Core Libraries XML-Based Application Creation Getting Started Guide (available here if you have Internet access).

Micro Application Generation is enabled by default in this release when compiling with rtime-make. However, future releases may disable the feature by default. Thus, it is advised to always compile with the Micro Application Generation feature enabled (-DRTIME_DDS_ENABLE_APPGEN=1 to cmake).

7.5.3.9. Ability to use only one UDP port per DomainParticipant

This release provides a way to use just one UDP port per DomainParticipant. The advantage of this is that by only using one UDP port, Connext DDS Micro will only create a receive thread, so fewer resources are used, mainly stack memory.

The disadvantage is that the port mappings used are not compliant with the OMG’s DDS Interoperability Wire Protocol and communication with other DDS implementations might not be possible.

You can only use this feature if multicast OR unicast is used for both discovery and user traffic. If both unicast AND multicast are configured, you cannot use this feature.

To enable this feature, assign the same value to both the builtin and user port offsets in RtpsWellKnownPorts_t.

7.5.3.10. New C++ DPSE example

This release includes a new C++ example that uses DPSE (dynamic participant - static endpoint) discovery.

7.5.4. What’s Fixed in 3.0.0

7.5.4.1. Linker error when using shared libraries on VxWorks systems

There was a linker error when compiling examples for architecture ppc604Vx6.9gcc4.3.3 using shared libraries. The compiler reported that the libraries could not be found. This issue has been fixed.

[RTI Issue ID MICRO-1841]

7.5.4.3. CPU endianness detection method improved

The CPU endianness detection method has been improved. Now the CMake endian test is used. If CMake is not used to compile, the compiler preprocessor macros are used to infer CPU endianness.

[RTI Issue ID MICRO-1919]

7.5.4.4. Examples used untyped register_type APIs instead of typed APIs

The provided examples have been updated to use FooTypeSupport_register_type() instead of DDS_DomainParticipant_register_type(). Using the typed API to register types is preferred over using the untyped API.

[RTI Issue ID MICRO-1922]

7.5.4.5. Wait_set generic error when returned condition sequence exceeded capacity

If the number of returned conditions exceeded the maximum size of the returned condition sequence, a generic error, DDS_RETCODE_ERROR, was returned instead of the expected error, DDS_RETCODE_OUT_OF_RESOURCES. This problem has been resolved.

[RTI Issue ID MICRO-1933]

7.5.4.6. WaitSet waited less than specified time period

A WaitSet may have waited less than the specified time period. This problem has been resolved.

[RTI Issue ID MICRO-1950]

7.5.4.7. Samples with deserialization errors were accepted

In previous versions, samples that could not be deserialized was rejected, causing samples to be resent when reliability was enabled. This behavior has been changed; now samples with deserialization errors are accepted and discarded.

[RTI Issue ID MICRO-1954]

7.5.4.8. Potential wrong API used when using host name as peer

The getaddrinfo() API was incorrectly used when a host name was used as a peer. That error might have caused a run-time error. This problem occurred only if compilation was done for Windows or if FACE compliance was enabled. This issue has been fixed.

[RTI Issue ID MICRO-1957]

7.6. Known Issues

7.6.1. Flow Controllers require RTOS

Flow controllers require RTOS. This will be addressed in the next release.