The shared-memory transport in Connext DDS 4.5f and higher does not interoperate with the shared-memory transport in previous releases of RTI Data Distribution Service.
If two applications, one using Connext DDS and one using RTI Data Distribution Service, run on the same node and they have the shared-memory transport enabled, they will fail with the following error:
[D0004|CREATE Participant|D0004|ENABLE] NDDS_Transport_Shmem_is_segment_compatible:incompatible shared memory protocol detected. Current version 1.0 not compatible with 2.0.
A possible workaround for this interoperability issue is to disable the shared-memory transport and use local communications over UDPv4 by setting participant_qos.transport_builtin to DDS_TRANSPORTBUILTIN_UDPv4.
If you have an interoperability requirement and you cannot switch to UDPv4, please contact support@rti.com.
In Connext DDS 5.1.0, the default message_size_max for the UDPv4, UDPv6, TCP, Secure WAN, and shared-memory transports changed to provide better out-of-the-box performance. Consequently, Connext DDS 5.1.0 is not out-of-the-box compatible with applications running older versions of Connext DDS or RTI Data Distribution Service.
To guarantee that communication between two applications always occurs: for a given transport, keep a consistent value for message_size_max in all applications within a Connext DDS system.
If you need compatibility with a previous release, you can easily revert to the transport settings used in Connext DDS 5.0.0. The new built-in Baseline.5.0.0 QoS profile contains all of the default QoS values from Connext DDS 5.0.0. Therefore, using it in a Connext DDS 5.1.0 application will ensure that Connext DDS 5.0.0 and 5.1.0 applications have compatible transport settings. Below is an example of how to inherit from this profile when configuring QoS settings:
<qos_profile name="MyProfile" base_name="BuiltinQosLib::Baseline.5.0.0"> ... </qos_profile>
The transport configuration can be adjusted programmatically or by using XML configuration. The following XML snippet shows how to change message_size_max for the built-in UDPv4 transport to match the Connext DDS 5.1.0 default setting of 65,507:
<participant_qos>
<property>
<value>
<element>
<name>
dds.transport.UDPv4.builtin.parent.message_size_max
</name>
<value>65507</value>
</element>
</value>
</property>
</participant_qos>
See Chapter 15, Transport Plugins, in the RTI Connext DDS Core Libraries User’s Manual for more details on how to change a transport’s configuration.
To help detect misconfigured transport settings, Connext DDS 5.1.0 will send the transport information, specifically the message_size_max, during participant discovery. Sharing this information will also make it easier for tools to report on incompatible applications in the system.
If two Connext DDS 5.1.0 DomainParticipants that discover each other have a common transport with different values for message_size_max, the Connext DDS core will print a warning message about that condition. Notice that older Connext DDS applications do not propagate transport information, therefore this checking is not done.
You can access a remote DomainParticipant’s transport properties by inspecting the new transport_info field in the DDS_ParticipantBuiltinTopicData structure. See Chapter 16, Built-in Topics, in the RTI Connext DDS Core Libraries User’s Manual for more details about this field. There is a related new field, transport_info_list_max_length, in the DomainParticipantResourceLimitsQosPolicy. See Table 8.12 in the RTI Connext DDS Core Libraries User’s Manual for more details about this field.
UDPv4, UDPv6, WAN, and TCP and Shared Memory show the new default transport settings.
|
|
Old Default (bytes) |
New Default (bytes) |
|
|
Non-INTEGRITY Platforms |
|||
|
message_size_max |
9,216 |
65,5072The value 65507 represents the maximum user payload size that can be sent as part of a UDP packet. |
9,216 |
|
send_socket_buffer_size |
9,216 |
131,072 |
131,072 |
|
recv_socket_buffer_size |
9,216 |
131,072 |
131,072 |
|
|
Old Default (bytes) |
New Default (bytes) |
|
|
Non-INTEGRITY Platforms |
INTEGRITY Platforms |
||
|
message_size_max |
9,216 |
65,536 |
9,216 |
|
received_message_count_max |
32 |
64 |
8 |
|
receive_buffer_size |
73,728 |
1,048,576 |
18,432 |
In Connext DDS 5.1.0, the way in which you provide a participant ID interval changed from [a,b] to [a-b].
In Connext DDS 5.2.0, the UDPv6 and SHMEM transport kinds changed to address an RTPS-compliance issue (RTI Issue ID CORE-5788).
|
Transport |
5.1.0 and lower |
5.2.0 and higher |
|---|---|---|
|
UDPv6 |
5 |
2 |
|
SHMEM |
2 |
0x01000000 (16777216) |
Because of this change, out-the-box compatibility with previous Connext DDS releases using both UDPv6 and SHMEM transports is broken. Connext DDS 5.1.0 and earlier applications will not communicate out-of-the-box with Connext DDS 5.2.0 applications over UDPv6 and SHMEM. (See below for how to resolve this.)
You may see the following error messages when the UDPv6 transport is not enabled:
5.1.0 Application:
can't reach: locator: transport: 16777216 address: 0000:0000:0100:0000:0000:0000:0000:0000 port: 21410 encapsulation: transport_priority: 0 aliasList: ""
5.2.0 Application:
PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'yyyyy' using the 'shmem' transport with class ID 2. This class ID does not match the class ID 16777216 of the same transport in the local participant 'xxxxx'. These two participants will not communicate over the 'shmem' transport. Check the value of the property 'dds.transport.use_510_compatible_locator_kinds' in the local participant. COMMENDBeWriterService_assertRemoteReader:Discovered remote reader using a non-addressable locator for a transport with class ID 2. This can occur if the transport is not installed and/or enabled in the local participant. See https://community.rti.com/kb/what-does-cant-reach-locator-error-message-mean for additional info. can't reach: locator: transport: 2 address: 0002:0000:0100:0000:0000:0000:0000:0000 port: 21412 encapsulation: transport_priority: 0 aliasList: ""
If you need compatibility with a previous release, there are two ways to do so:
<participant_qos>
<property>
<value>
<element>
<name>
dds.transport.use_510_compatible_locator_kinds
</name>
<value>1</value>
</element>
</value>
</property>
</participant_qos>
<qos_profile name="MyProfile" base_name="Generic.510TransportCompatibility"> ... </qos_profile>
In Connext DDS 5.2.0, the SHMEM transport has changed to address a potential bus error on Solaris platforms on Sparc 64-bit CPUs3RTI Issue ID CORE-6777 (). The change is not backward compatible with previous Sparc Solaris releases (32-bit or 64-bit).
If a 5.2.0 application tries to communicate with an older version using the shared memory transport, you will see this error:
[D0004|CREATE Participant|D0004|ENABLE] NDDS_Transport_Shmem_is_segment_compatible: incompatible shared memory protocol detected. Current version 3.0 not compatible with x.0.
To avoid this error, disable the shared memory transport by setting the QoS policy participant_qos.transport_builtin so that it does not contain the shared memory transport. For example:
<participant_qos>
<transport_builtin>
<mask>UDPv4</mask>
</transport_builtin>
</participant_qos>
© 2015 RTI