How to configure apps for backward compatibility 5.1.0 to 5.0.0

We have changed the default transport settings for RTI Connext DDS 5.1.0 to support better out-of-the-box throughput.  This gives better performance, and in some cases reduces the time of the discovery process.

However, this means that you must change your applications' transport settings in order to communicate between applications linking against RTI Connext DDS versions 5.1.0 and 5.0.0.

Your Applications

You have three options for ensuring compatibility between your 5.0.0 and 5.1.0 applications:

1. Configuring your 5.1.0 applications using builtin profiles to be backward compatible
2. Configuring your 5.1.0 applications manually in XML or source to be backward compatible
3. Configuring your 5.0.0  applications to be forward compatible

The first two options allow you to configure your new applications to be backward compatible.  The downside of using these two options is that you will not get the better throughput capabilities of the new settings.  However, if you cannot modify your existing 5.0.0 (or earlier) applications, they will allow your new applications to communicate consistently with your current applications.  The third option is to modify the settings of your 5.0.0 applications to be forward-compatible with your 5.1.0 applications, which will allow the applications to communicate correctly with the increased throughput of the new settings.

Also note that even if you are only using 5.1.0, if part of your distributed system includes RTI Connext DDS applications running on INTEGRITY, you must modify your QoS in all applications to use the 5.0.0 settings, as that platform does not support larger message sizes. 

1. Use the new builtin profiles feature to choose the backward-compatible profile.

The transport sizes are a QoS setting that affects only your DomainParticipants.  You can configure this in multiple ways.  

You can configure your participant_qos in XML so your DomainParticipants inherit the old transport settings: 

 <participant_qos base_name="BuiltinQosLib::Baseline.5.0.0">

or your entire XML QoS profile can inherit the old transport settings:

 <qos_profile name="profiles_Profile" base_name="BuiltinQosLib::Baseline.5.0.0" is_default_qos="true">

Alternately, you can configure your DomainParticipants in code at creation time using create_participant_with_profile:

/* You can either use constants or manually type the strings "BuiltinQosLib" 
   and "Baseline.5.0.0" */
participant = DDSTheParticipantFactory->create_participant_with_profile(
                domainId, DDS_BUILTIN_QOS_LIB, 
                DDS_PROFILE_BASELINE_5_0_0,
                NULL /* listener */, DDS_STATUS_MASK_NONE); 

There is a full example showing how to use the new built-in QoS profiles in XML or code on our examples page.  The string constants that represent the built-in QoS libraries and policies is documented in our HTML documentation. 

2. Configure the QoS of your new 5.1.0 applications in XML to be backward compatible.

You can also manually edit your new applications' XML to be backward compatible:

<participant_qos>
  <property>
    <value> 
      <element>
        <name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
        <value>9216</value> 
      </element>     
      <element>
        <name>dds.transport.shmem.builtin.parent.message_size_max</name>
        <value>9216</value>
      </element>
    </value>
  </property> 
</participant_qos> 

3. Configure the QoS of your existing 5.0.0 applications to be forward-compatible.

<participant_qos>
  <property>
    <value> 
      <element>
        <name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
        <value>65507</value> 
      </element>     
      <element>
        <name>dds.transport.shmem.builtin.parent.message_size_max</name>
        <value>65536</value>
      </element>
    </value>
  </property> 
</participant_qos> 

RTI Tools

ROUTERDdsConnection_assertType:!Mutable types are not supported 
ROUTERDdsConnection_assertType:!RTI::RoutingService::Administration::CommandRequest

If you do not change your transport settings to be compatible, you may see a range of incorrect behavior, including:

• No discovery when communicating over UDP
• Partial discovery when communicating over UDP
• Complete data loss when communicating over UDP
• Partial data loss when communicating over UDP
• The following error message when communicating over shared memory: 

  NDDS_Transport_Shmem_attach_writer:incompatible shared memory segment found. Found segment with max message size 9216. Needed 65536.