Home / , , / Is OpenSplice DDS compatibile with DDS from other vendors?

Is OpenSplice DDS compatibile with DDS from other vendors?

Yes, OpenSplice DDS is compatible with DDS from other vendors.  To get OpenSplice DDS to interoperate with other vendors you will need to configure OpenSplice DDSI2 networking service. correctly.

The DDSI2 service in OpenSplice has three compliance modes, pedantic, strict and lax. More details can be found in the  OpenSplice Deployment Guide.

DDSI2 Service Configuration.

The default mode, lax, attempts to work around (most of) the deviations of other DDS implementations, and provides interoperability with (at least) RTI DDS and InterCOM/Gallium DDS. (For compatibility with TwinOaks CoreDX DDS, additional settings are needed. See the next section for more information.). In lax mode, the OpenSplice DDSI2 service not only accepts some invalid messages but will even transmit them. The consequences for interoperability of not doing this are simply too severe. It should be noted that if one configures two OpenSplice nodes with DDSI2 in different compliancy modes, the one in the stricter mode will complain about messages sent by the one in the less strict mode. Pedantic mode will complain about invalid encodings used in strict mode; strict mode will complain about illegal messages transmitted by the lax mode. There is nonetheless interoperability between strict and lax.

Compatibility with RTI DDS

In lax mode, there should be no major issues with most topic types when working across a network, but within a single host there is a known problem with the way RTI DDS uses, or attempts to use, its shared memory transport to communicate with OpenSplice, which clearly advertises only UDP/IP addresses at which it is reachable. The result is an inability to reliably establish bidirectional communication between the two.

Disposing data may also cause problems, as RTI DDS leaves out the serialised key value and instead expects the reader to rely on an embedded hash of the key value. In the strict modes, the DDSI2 service requires a proper key value to be supplied; in the relaxed mode, it is willing to accept key hash, provided it is of a form that contains the key values in an unmangled form.

If an RTI DDS data writer disposes an instance with a key of which the serialised representation may be larger than 16 bytes, this problem is likely to occur. In practice, the most likely cause is using a key as string, either unbounded, or with a maximum length larger than 11 bytes. See the DDSI specification for details.

In strict mode, there is interoperation with RTI DDS, but at the cost of incredibly high CPU and network load, caused by a Heartbeats and AckNacks going back-and-forth between a reliable RTI DDS data writer and a reliable OpenSplice DCPS data reader. The problem is that once the OpenSplice reader informs the RTI writer that it has received all data (using a valid AckNack message), the RTI writer immediately publishes a message listing the range of available sequence numbers and requesting an acknowledgement, which becomes an endless loop.

The best settings for interoperation appear to be:

  • OpenSplice/DDSI2Service/Compatibility/StandardsConformance: lax
  • OpenSplice/DDSI2Service/Compatibility/AckNackNumbitsEmptySet: 0

Note that the latter setting causes the DDSI2 service to generate illegal messages and is the default when in lax mode. Please refer to the Deployment Guide for detailed descriptions of:

  • OpenSplice/DDSI2Service/Compatibility/StandardsConformance
  • OpenSplice/DDSI2Service/Compatibility/AckNackNumbitsEmptySet

Compatibility with Twin Oaks CoreDX

Interoperability with TwinOaks CoreDX requires:

  • OpenSplice/DDSI2Service/Compatibility/ManySocketsMode: true
  • OpenSplice/DDSI2Service/Compatibility/StandardsConformance: lax
  • OpenSplice/DDSI2Service/Compatibility/AckNackNumbitsEmptySet: 0
  • OpenSplice/DDSI2Service/Compatibility/ExplicitlyPublishQosSetToDefault: true

The ManySocketsMode option needs to be changed from the default, to ensure that each domain participant has a unique locator; this is needed because TwinOaks CoreDX DDS does not include the full GUID of a reader or writer if it needs to address just one. Note that the behaviour of TwinOaks CoreDX DDS is allowed by the specification.

The Compatibility/ExplicitlyPublishQosSetToDefault settings work around TwinOaks CoreDX DDS’ use of incorrect default values for some of the QoS settings if they are not explicitly supplied during discovery. Please refer to the Deployment Guide for detailed descriptions of:

  • OpenSplice/DDSI2Service/Compatibility/ManySocketsMode
  • OpenSplice/DDSI2Service/Compatibility/StandardsConformance
  • OpenSplice/DDSI2Service/Compatibility/AckNackNumbitsEmptySet
  • OpenSplice/DDSI2Service/Compatibility/ExplicitlyPublishQosSetToDefault