Jump to content
OpenSplice DDS Forum
loay

OpenSplice and OpenDDS Interoperability

Recommended Posts

loay   

Hello,

 

I already posted this question in the general discussion section but maybe posting it here is more appropriate.

 

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

 

They are both using rtps as protocol, but they are not communicating.

They are both using the same domain id and the destination port is the same for both programs (I verified using wireshark).

 

I don't know if I am doing anything wrong with the config... I am using the basic config for OpenDDS 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>

Any help is appreciated!

Thanks !

 

Share this post


Link to post
Share on other sites

Are you using DDS::DOMAIN_ID_DEFAULT in your application as using that will cause the application to automatically select the same Domain ID as is present in the configuration file.

 

For more information, see:

- DeploymentGuide - //OpenSplice/Domain/Id

- C++ Reference Guide - create_participant

 

Maybe you can share your application ?

Share this post


Link to post
Share on other sites
loay   

Hello Hans,

 

My Domain_ID is 223 both in my code and the config file.

 

I attached both applications.

 

I am using ACE 6.1.1, TAO 2.1.1 for OpenSplice and ACE 6.4.2, TAO 2.4.2 for OpenDDS. For both projects I used Qtcreator with Qt5. 

 

Thanks a lot !

 

BR,

 

Loay

 

 

Communication.tar.gz

Share this post


Link to post
Share on other sites

I see that you're using modules in your IDL. In previous interop-tests at the OMG we used the iShapes example with a module-less IDL as the spec didn't prescribe how these 'scoped-types' appear on the wire.

So you might want to give it a try with module-less IDL.

 

Looking at ICO's ShapeType.idl, I notice that at some point they changed the idl to org::omg::dds:demo::ShapeType, but in our interop-version there's no modules specified as that didn't work-out between vendors.

Share this post


Link to post
Share on other sites
loay   

I modified my IDLs and made them module-less but still no interoperability.

 

I also tested with the iShapes example (using qt4) and both ishapes don't communicate.
I modified the IDL of iShapes provided by OpenDDS and made it module-less and did the necessary modifications on the source files but still no interoperability between both iShapes.

 

I included my application( with module-less IDL ) and OpenDDS's iShapes with the modifications made.

 

BR,

 

Loay

Communication_modules.tar.gz

ishapes_opendds.tar.gz

Share this post


Link to post
Share on other sites
erik   

Hi Loay,

 

Perhaps the problem is with the selection of the network interface to use if you have multiple network interfaces. I don't know about OpenDDS, but the DDSI2 service is somewhat picky in that it really wants to use a single interface. It could well be that the two simply don't receive each other's multicasts.

 

You can specify the interface (by name or by IP address) in the "General/NetworkInterfaceAddress" parameter.

 

When all else fails ... try enabling DDSI2's tracing by adding:

<Tracing>

 <EnableCategory>trace,plist</EnableCategory>
</Tracing>

 

to the DDSI2Service section in the ospl.xml file. This consists of a dump of the configuration, then stuff about network interfaces, addresses, port numbers, &c., and finally you get all the traffic and discovery. This may help in finding out what network interface to use, but it usually also gives valuable information for more complicated problems.

 

It would be unreasonable to expect you to understand everything that is that trace file, so feel free to post fragments of it if you need further help.

 

Best regards,

Erik

Share this post


Link to post
Share on other sites
loay   

Hello Erik,

 

I used wireshark to trace the packets and I noticed something interesting:

OpenSplice is using the right interface to communicate, it is periodically sending 3 packets that have the same length ( I attached a screen-shot of the packets ) but when I publish my data, the publisher receives but I see nothing on wireshark ! There is no trace of the data that is sent !

 

When I use openDDS with openSplice, when a participant is connected openDDS starts sending HEARTBEAT packets which is a normal behavior when another participant is detected ! However the data sent and the disconnection remain not detected ! 

I added the IP address as you advised : <NetworkInterfaceAddress>10.0.2.15</NetworkInterfaceAddress>

 

I also added tracing but I don't really understand the output but I noticed these lines that are repeated multiple times :

1490179214.575447/ xmit.user: rtps_write(gid 23410643:18:1) - unknown gid
1490179214.575449/ xmit.user: message dropped because sender 23410643:18:1 is unknown

 

and also there is this line that is also repeated : 1490179214.572088/      main: match_writer_with_proxy_readers(wr 23410643:a8:1:100c2) scanning proxy participants tgt=0 
what is the proxy ??

I also attached the trace file if you can help me with it

 

Thanks !

 

BR,

 

Loay

post-18952-0-43964900-1490179628_thumb.png

ddsi2.log.tar.gz

Share this post


Link to post
Share on other sites
erik   

Hi Loay,

 

It is obvious that OpenDDS and OpenSplice are not talking, as OpenSplice doesn't receive a single packet from OpenDDS. Each packet contains a "vendor code", PrismTech's is 1.2, and there no packets with a vendor code other than 1.2 — I think OpenDDS uses 1.3, but it is just as easy to check for anything else. Try, e.g., "grep -E 'vendor 1\.([013-9]|2[0-9])'".

 

Absolutely nothing happens unless both sides receive participant discovery data (SPDP) from each other. So if you see a hint of OpenDDS responding to OpenSplice, but nothing actually working, then the first thing to check is where OpenDDS is sending its SPDP data and why that isn't received by OpenSplice. In WireShark, the SPDP data is shown in the summary as DATA(p), so that's easy to spot.

 

About the "proxy" thing: the world in DDSI is divided into two sides: the entities, and the proxy entities. The first are local, the proxy entities are where it stores information on the remote entities such as the locators, last sequence number received, what sequence numbers have been acknowledged so far, &c., &c. The DDSI endpoint discovery (SEDP) distributes the information on the readers and writers, so that every party in the network is aware of who is out there, and what data needs to be send to whom. The "match_writer_with_proxy_readers" therefore is about matching local writers with remote readers, which determines the destination IP addresses to use and from whom to expect acknowledgements.

 

Also note that the "plist" keyword messes up the trace but helps debug issues with the encoding/interpretation of the QoS and various other things that are transmitted as part of the discovery. If you leave it out, then you can easily search for new participants using the regular expression "SPDP.*NEW". As the case is now, it is a bit harder because it is split over multiple lines. Still, "bes .*NEW" works.

 

Best regards,

Erik

Share this post


Link to post
Share on other sites
loay   

Hello Erik,

 

I just noticed that both don't use the same version of the RTPS protocol. OpenDDS uses RTPS 2.2 and OpenSplice uses RTPS 2.1. Are they compatible ? if not this can be the source of the problem.

 

Thanks a lot for your help I'll continue investigating!

 

Best regards,

 

Loay

Share this post


Link to post
Share on other sites

Hi Loay,

 

Your wireshark capture only shows data from 10.0.2.15 which (according to the DDSI-traces) is the 'OpenSplice machine' .. so why doesn't it show any OpenDDS data ??

 

And finally, as you're using 6.7.1, you're not using the community-edition so you should also have access to our tools such as the OpenSplice Tester which includes a browser that should show discovered participants (even those that are not 'ours' :)

 

Thanks

Hans

Share this post


Link to post
Share on other sites
loay   

Hi Hans,

 

I have OpenDDS and OpenSplice both working on the same machine (different terminals using different environment variables), so 10.0.2.15 is the address used by OpenSplice and OpenDDS. 

I will try using the tester and see if anything is detected.

 

Thanks!

BR,
Loay

Share this post


Link to post
Share on other sites

you might even try if it works when actually using two different machines (as co-location can also cause its own issues depending how 'smart' implementations are to apply 'shortcuts' in such situations) .. 

Share this post


Link to post
Share on other sites
loay   

Hello Hans,

 

Thanks a lot for your help and tips. Unfortunately I currently don't have access to other machines. I'll try to get access and get back to you if anything new comes up!

 

BR,

 

Loay

Share this post


Link to post
Share on other sites
loay   

Hi Erik,

I think I found the problem. It is a shared memory issue, OpenSplice uses shared memory when the processes are on the same machine but OpenDDS does not do the same, it only uses networking.
I installed RTI's DDS which uses both networking and shared memory to communicate and it was interoperable with both OpenSplice and OpenDDS.

Is there a way to force OpenSplice to use only networking ?

I also attached WireShark captures as you demanded (OpenDDS alone, OpenSplice alone, OpenDDS+OpenSplice). I use the ishapes example.

Use case 1: Pub and Sub to circle using OpenDDS.

Use case 2: Pub and Sub to circle using OpenSplice.

Use case 3: Pub circle using OpenDDS and sub to circle using OpenSplice.

 

BR,

Loay

Captures.tar.gz

Share this post


Link to post
Share on other sites
erik   

Hi Loay,

 

In a shared-memory deployment OpenSplice uses shared memory to communicate between the OpenSplice applications that are attached to that shared memory, but for everything else it relies on the networking service, i.e., DDSI2. With a bit of trickery you can even have two independent shared memory domains running inside a single machine, and then connect them via DDSI2. So no, OpenSplice's shared memory is not in any way relevant here.

 

Both OpenSplice and OpenDDS are multicasting to 239.255.0.1:7400 but there is no indication either of them receives anything — and I am certain OpenSplice did not receive anything from OpenDDS in the ddsi2.log file you sent earlier and from the traffic that it generates. I know I have at times had problems with multicasting in a VM, especially if the VM was in a NAT configuration, and I suspect this may be the case for you as well.

 

That means as a next step I think you should try enabling unicast discovery (and probably disable multicasting altogether). In OpenSplice that is pretty straightforward:

- set General/AllowMulticast to false

- add a <Discovery><Peers><Peer address="localhost"/></Peers></Discovery>

Obviously this is not a desirable configuration, but if it turns out that it is a virtual networking problem, then I don't think there are many alternatives short of configuring your VM differently. In any case, it is a sensible step to gain some further understanding of the problem.

Share this post


Link to post
Share on other sites
loay   

Hello Erik,

 

I did as you said but still no communication between both. What I don't understand is how can RTI's DDS communicate with OpenSplice and OpenDDS but both can't communicate!

I will try installing these implementations on different Raspberry pis and see if this resolves the issue.

 

BR,

Loay

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×