OpenDDS and OpenSplice interoperability

Question

I have two programs, one using OpenSplice 6.7.1 and the other using OpenDDS 3.10.

They are both using RTPS as protocol, the same domain id and the destination port (I verified using wireshark).

The problem is that they are not communicating.

I don't know if I am doing anything wrong with the config... I am using the basic config for OpenDDS with RTPS and for OpenSplice I used the provided ospl.xml after changing the domain ID.

Here are my config files. For OpenDDS:

[common]
DCPSGlobalTransportConfig=$file
DCPSDefaultDiscovery=DEFAULT_RTPS
[transport/the_rtps_transport]
transport_type=rtps_udp

For OpenSplice:

<OpenSplice>
    <Domain>
        <Name>ospl_sp_ddsi</Name>
        <Id>223</Id>
        <SingleProcess>true</SingleProcess>
        <Description>Stand-alone 'single-process' deployment and standard DDSI networking.</Description>
        <Service name="ddsi2">
            <Command>ddsi2</Command>
        </Service>
        <Service name="durability">
            <Command>durability</Command>
        </Service>
        <Service name="cmsoap">
            <Command>cmsoap</Command>
        </Service>
    </Domain>
    <DDSI2Service name="ddsi2">
        <General>
            <NetworkInterfaceAddress>AUTO</NetworkInterfaceAddress>
            <AllowMulticast>true</AllowMulticast>
            <EnableMulticastLoopback>true</EnableMulticastLoopback>
            <CoexistWithNativeNetworking>false</CoexistWithNativeNetworking>
        </General>
        <Compatibility>
            <!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability -->
            <StandardsConformance>lax</StandardsConformance>
            <!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility -->
            <!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> -->
        </Compatibility>
    </DDSI2Service>
    <DurabilityService name="durability">
        <Network>
            <Alignment>
                <TimeAlignment>false</TimeAlignment>
                <RequestCombinePeriod>
                    <Initial>2.5</Initial>
                    <Operational>0.1</Operational>
                </RequestCombinePeriod>
            </Alignment>
            <WaitForAttachment maxWaitCount="100">
                <ServiceName>ddsi2</ServiceName>
            </WaitForAttachment>
        </Network>
        <NameSpaces>
            <NameSpace name="defaultNamespace">
                <Partition>*</Partition>
            </NameSpace>
            <Policy alignee="Initial" aligner="true" durability="Durable" nameSpace="defaultNamespace"/>
        </NameSpaces>
    </DurabilityService>
    <TunerService name="cmsoap">
        <Server>
            <PortNr>Auto</PortNr>
        </Server>
    </TunerService>
</OpenSplice>

What am I doing wrong ?

Answer 1

Multi-vendor interoperability has been demonstrated repeatedly at OMG events but not recently, so maybe a regression has happened with/in either of the products.

Your OpenSplice configuration is (apart from domainId which should match the one used in your application where typically users use DDS::DOMAIN_ID_DEFAULT to indicate they want to use the ID as specified in the configuration as pointed to by the OSPL_URI environment variable) a proper default configuration. I'm sure you are aware that the AUTO setting of the to-be-used interface/IP-address is a potential source-of-confusion if you use multi-homed machines.

So next would be to look at both (DDSI)traces and/or wireshark captures and see if you spot DDSI wire-frames for both Vendors (1.2 for PrismTech, 1.3 for OCI).

When for instance there's no sign of vendor-1.3 being identified in OpenSplice DDSI-traces then that suggests there's still some 'fundamental' communication issues.

Note that at these OMG-events we typically used the (for us 'bundled') iShapes example on domain '0' and module-less IDL topic-type specification to verify interoperability, so it it doesn't work for your application that's something worth trying too (and check/use wireshark in combination with that example too)

I'll also keep watching the community-forum for new information on this ..