3.2.1. RTI Connext DDS Core Libraries

The following issues affect backward compatibility in the Core Libraries starting in Release 6.0.0. Issues in the Core Libraries may affect components that use these libraries, including services and tools.

3.2.1.1. Application Binary Interface

RTI Connext DDS does not provide Application Binary Interface (ABI) compatibility with previous versions of Connext DDS. Therefore, an application compiled using a previous version of Connext DDS must be recompiled when moving to Connext DDS 6.0.0 or 6.0.1.

The Connext DDS core primarily consists of libraries and a set of header files. In most cases, upgrading simply requires you to recompile your source using the new header files and link your application with the new libraries. In some cases, minor modifications to your application code might be required; any such changes are noted in this Migration Guide.

To upgrade to release 6.0.0, first review the information in Section 3.1 and in Section 3.2 to see what modifications you may need to make to your application code; further see Section 2.1 if you are upgrading to 6.0.1. You may also want to see What’s New in 6.0.0 or What’s New in 6.0.1, as well as the Core Libraries Release Notes, to see what is new or changed in Connext 6. Then recompile your source using the new header files and link the new libraries.

3.2.1.2. APIs

The following Application Program Interfaces (APIs) have been changed or deprecated in 6.0.0. For new APIs, see What’s New in 6.0.0.

3.2.1.2.1. Wchar and wstring language binding changes

See information about this change in Section 3.1.4.5.

3.2.1.2.2. Dynamic Data compatibility issues

3.2.1.2.2.1. Deprecated APIs

In 6.0.0, the DynamicData::set_buffer and DynamicData::get_estimated_max_buffer_size APIs have been deprecated. If you were using these APIs to get a CDR of the DynamicData object, then DynamicData::to_cdr_buffer should be used for that instead.

3.2.1.2.2.2. Unsupported members

Starting in 6.0.0, the following members in the DynamicDataTypeSerializationProperty_t are no longer supported:

  • use_42e_compatible_alignment (see Section 3.1.2.4)
  • max_size_serialized
  • min_size_serialized

The size of the DynamicData buffers in the DataReader’s queue are now controlled by the fields buffer_initial_size and buffer_max_size in the DynamicDataTypeProperty_t::data field.

It is no longer required to set anything in the DynamicDataTypeProperty_t in order to support unbounded types for a DynamicData DataReader. The default behavior for a DynamicData DataReader is that samples are allocated to the minimum deserialized size and can grow to any size required to store incoming samples.

3.2.1.3. Generated Code

3.2.1.3.1. Generated code compatibility

For Connext DDS applications defining types in IDL, XML, or XSD, moving from a previous Connext DDS version to Connext DDS 6.0.0 or 6.0.1 requires code regeneration and recompilation.

You will need to regenerate the code for your application types using the RTI Code Generator shipped with 6.0.0 or 6.0.1. The regeneration process is very simple; you only need to run the new version of RTI Code Generator using the original input IDL file. (You should see a message that says you are running rtiddsgen version 3.0.0 if you are upgrading to 6.0.0 or rtiddsgen version 3.0.1 if you are upgrading to 6.0.1.) This process will regenerate the header and source files, which can then be compiled along with the rest of your application.

3.2.1.3.2. Changed modern C++ default IDL mapping

In 5.3.0, a new option, -stl, was introduced to change the mapping of some of the IDL types, when combined with -language C++03 or -language C++11. From 6.0.0 onward, -stl is the default option when generating code for C++03/C++11. A new option, -legacyPlugin, has been introduced to generate code using the old mapping.

Starting in 6.0.0, the following IDL types have the following default mapping:

  • Unbounded sequences map to std::vector (when -unboundedSupport is also specified)
  • Bounded sequences map to rti::core::bounded_sequence<T, Bound>, unless the sequence member has the annotation @use_vector or rtiddsgen is run with the command-line option -alwaysUseStdVector, in which case they also map to std::vector.
  • Strings map to std::string.
  • Wide strings map to std::wstring, wide characters map to wchar_t.
  • Members with the new annotation @external (equivalent to the * pointer notation) map to the type dds::core::external<T>, a type similar to shared_ptr (see the API Reference HTML documentation for more details).

For example, consider the following IDL type:

struct MyType {
    sequence<long> my_unbounded_seq;
    sequence<long, 10> my_bounded_seq;
    @use_vector sequence<long, 10> my_other_bounded_seq
    string my_str;
    @external long my_external;
};

This is how the generated C++11 type looks starting in 6.0.0:

rtiddsgen -language C++11 -unboundedSupport MyType.idl
class MyType {
    public:
    MyType();
    MyType(const std::vector<int32_t>& my_unbounded_seq,
           const rti::core::bounded_sequence<int32_t,
            10>& my_bounded_seq,
            const std::vector<int32_t>& my_other_bounded_seq,
            const std::string& my_str,
            dds::core::external<int32_t> my_external);


    MyType (MyType&&) = default;
    MyType& operator=(MyType&&) = default;
    MyType& operator=(const MyType&) = default;
    MyType(const MyType&) = default;


    std::vector<int32_t>& my_unbounded_seq() noexcept;
    const std::vector<int32_t>& my_unbounded_seq() const noexcept;


    void my_unbounded_seq(const std::vector<int32_t>& value);
    rti::core::bounded_sequence<int32_t, 10>& my_bounded_seq() noexcept;


    const rti::core::bounded_sequence<int32_t, 10>& my_bounded_seq() const noexcept;
    void my_bounded_seq(const rti::core::bounded_sequence<int32_t, 10>& value);

    std::vector<int32_t>& my_other_bounded_seq() noexcept;
    const std::vector<int32_t>& my_other_bounded_seq() const noexcept;

    void my_other_bounded_seq(const std::vector<int32_t>& value);
    std::string& my_str() noexcept;
    const std::string& my_str() const noexcept;

    void my_str(const std::string& value);
    dds::core::external<int32_t>& my_external() noexcept;
    const dds::core::external<int32_t>& my_external() const noexcept;
    void my_external(dds::core::external<int32_t> value);

    bool operator == (const MyType& other_) const;
    bool operator != (const MyType& other_) const;

    void swap(MyType& other_) noexcept ;
};

If you want to generate code using the old mapping, enter the following:

rtiddsgen -language C++11 -legacyPlugin -unboundedSupport MyType.idl
class MyType {
    public:
        MyType();
        MyType(
            const dds::core::vector<int32_t>& my_unbounded_seq_param,
            const dds::core::vector<int32_t>& my_bounded_seq_param,
            const dds::core::vector<int32_t>& my_other_bounded_seq_param,
            const dds::core::string& my_str_param,
            int32_t * my_external_param);

        MyType (MyType&&) = default;
        MyType& operator=(MyType&&) = default;
        MyType& operator=(const MyType&) = default;
        MyType(const MyType&) = default;

        dds::core::vector<int32_t>& my_unbounded_seq() noexcept;
        const dds::core::vector<int32_t>& my_unbounded_seq() const noexcept;
        void my_unbounded_seq(const dds::core::vector<int32_t>& value);

        dds::core::vector<int32_t>& my_bounded_seq() noexcept;
        const dds::core::vector<int32_t>& my_bounded_seq() const noexcept;
        void my_bounded_seq(const dds::core::vector<int32_t>& value);

        dds::core::vector<int32_t>& my_other_bounded_seq() noexcept;
        const dds::core::vector<int32_t>& my_other_bounded_seq() const noexcept;
        void my_other_bounded_seq(const dds::core::vector<int32_t>& value);

        dds::core::string& my_str() noexcept;
        const dds::core::string& my_str() const noexcept;
        void my_str(const dds::core::string& value);

        int32_t * my_external() const noexcept;
        void my_external(int32_t * value);

        bool operator == (const MyType& other_) const;
        bool operator != (const MyType& other_) const;

        void swap(MyType& other_) noexcept;
};

3.2.1.4. QoS

3.2.1.4.1. Properties dds.type_consistency.ignore_member_names and dds.type_consistency.ignore_sequence_bounds have been deprecated

In 6.0.0, the QoS properties dds.type_consistency.ignore_member_names and dds.type_consistency.ignore_sequence_bounds have been deprecated. The properties are still supported for backward compatibility reasons, but future releases may stop supporting them.

The functionality provided by these properties is provided in the TYPE_CONSISTENCY_ENFORCEMENT QosPolicy, which is part of the (DDS-XTypes) specification from the Object Management Group (OMG).

dds.type_consistency.ignore_member_names has been replaced with the standard reader_qos.type_consistency.ignore_member_names and reader_qos.type_consistency.ignore_enum_literal_names. If you were setting the property dds.type_consistency.ignore_member_names to “true,” you must now set both reader_qos.type_consistency.ignore_member_names and reader_qos.type_consistency.ignore_enum_literal_names to true to preserve the same behavior.

dds.type_consistency.ignore_sequence_bounds has been replaced with the standard reader_qos.type_consistency.ignore_sequence_bounds and reader_qos.type_consistency.ignore_string_bounds. If you were setting the property dds.type_consistency.ignore_sequence_bounds to “true,” you must now set both reader_qos.type_consistency.ignore_sequence_bounds and reader_qos.type_consistency.ignore_string_bounds to true to preserve the same behavior.

For additional information, see the RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types.

3.2.1.5. Library Size

In 6.0.0, the size of the libraries increases compared to 5.3.1, due to the addition of a significant amount of functionality. The following table shows the differences:

Table 3.2 Library Size Comparison for x64Linux3gcc4.8.2 in MBs
  5.3.1 6.0.0 Change (%)
libnddscpp.so 1.42 1.49 +5
libnddscpp2.so 0.93 0.96 +3
libnddsc.so 5.3 5.86 +10
libnddscore.so 5.63 6.07 +7

3.2.1.6. Memory Consumption

In general, 6.0.0 applications will consume more heap memory than 5.3.1 applications. Stack size is similar between the two releases; there are no significant changes in the stack size.

The following table shows the heap memory differences:

Table 3.3 Memory Comsumption Comparison for x64Linux3gcc4.8.2 in Bytes
  5.3.1 6.0.0 Change (%)
Participant 1936149 1946776 +0.55
Type 1492 1610 +7.91
Topic 2090 2187 +4.64
Subscriber 14356 14798 +3.08
Publisher 3515 3727 +6.03
DataReader 82975 85926 +3.56
DataWriter 44291 45757 +3.31
Instance 461 480 +4.12
Sample 1317 1340 +1.75
Remote DataReader 6628 6529 -1.49
Remote DataWriter 14300 14698 +2.78
Instance registered in DataReader 962 980 +1.87
Sample stored in DataReader 877 894 +1.94
Remote Participant 73167 73255 +0.12

3.2.1.7. Performance

There are no significant performance differences in throughput between 6.0.0 applications and 5.3.1 applications; however, 6.0.0 has changed the way code generation works for IDL types to support XCDR2 network representation. We have observed that throughput for small data samples and simple types is slightly worse in 6.0.0, especially when using batching.

Table 3.4 C++/Keyed/Throughput (Mbps)
  5.3.1 6.0.0 Change (%)
32 165.7 163.3 1.5
64 317.7 317.8 0.1
128 609.2 593.5 2.6
256 868.9 868.7 0.1
1024 952.6 952.6 0
4096 974.4 974.4 0
8192 981.6 981.6 0
63000 991.2 991.2 0

3.2.1.8. RTI Connext DDS Micro Compatibility

Connext DDS Micro 2.4.11 and below does not communicate with any Connext DDS 6.0.0 product, due to a change in the RTPS version number introduced in 6.0.0. (See “Fixes Related to OMG Specification Compliance” in the RTI Connext DDS Core Libraries Release Notes.) If you need Connext DDS Micro 2.4.11 applications or below to communicate with Connext DDS 6.0.0 applications, see the article Workaround for discovery failure between RTI Connext DDS Micro 2.4.11 and RTI Connext DDS 6.0.0 or contact RTI Support at support@rti.com.

This issue has been fixed in Connext DDS Micro 2.4.12, which does communicate with a Connext DDS 6.0.x product.