8.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 OS and CPU. Please refer to the following tables for a list of specific platforms and the specific configurations that are tested by RTI.

Table 8.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 8.2 Supported Windows Platforms
OS CPU Compiler RTI Architecture Abbreviation
Windows 7 x86 Visual Studio 2010 i86Win32VS2010
Table 8.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 PPC32 e500v2 gcc 4.1.2 ppce500v2VxCert6.6.4.1gcc4.1.2

8.2. Compatibility

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

8.3. What’s New in 3.0.0

8.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:

8.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.

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 22 Sending Large Data chapter in the RTI Connext DDS Core Libraries User’s Manual.

8.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.

8.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.

8.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.

8.3.6. Support for KEEP_ALL History

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

8.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.

8.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 refer to the Chapter 6 Generating Applications for Connext DDS Micro in the RTI Connext DDS Core Libraries XML-Based Application Creation Getting Started Guide and the Application Generation section of the RTI Connext DDS Micro User’s Manual for details. The 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).

8.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.

8.3.10. New C++ DPSE example

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

8.4. What’s Fixed in 3.0.0

8.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]

8.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]

8.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]

8.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]

8.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]

8.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]

8.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]

8.5. Known Issues

8.5.1. Flow Controllers require RTOS

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