Interoperability between RTI and OpenSplice

Hello,

Are you running both applications on the the same computer or on different computers?

If you are running on the same computer, then you would need to configure the RTI application to not use the shared-memory transport. This can be done using the DomainParticipant Qos, the easiest way would be to use the USER_QOS_PROFILES.xml file. The use of shared-memory is an optimization that automatically happens when two DDS DomainParticipats run on the same compoter, but it does not interoperate with OpenSplice...

If you need help configuring RTI to not use the shared memory transport let us know and I will post an example XML file to achieve this.

If the problem is indeed this (running on the same computer) you could do a simple test. Run rtiddsspy passing the option -transport 1  this tells rtiddsspy to only use the UDPv4 transport and you should then be able to see how the OpenSplice application produces data (but not the data content).

With regards to the ports being different. Are you referrring to the Unicast ports? It is normal that they woukd be different, especially if they are running on the same computer bacuse a unicast UDP port can only be bound to a single process.

Gerardo

You can disable shared memory in the xml using the transport builtin mask.

Here there is an example:

<qos_library name="QosLibrary">
    <qos_profile name="DefaultProfile" is_default_qos="true">
        <participant_qos>
            <transport_builtin>
                <mask>UDPV4</mask>
            </transport_builtin>
        </participant_qos>
    </qos_profile>
</qos_library>

Best,
  Gianpiero

Hello Rafael, 

the xml file is not used at compile or generation files. It used at run time. Basically you can set the qos in the code or you can set all of them in an xml file that gets loaded at run time and used to configure the DDS entities.

For examle, if there is an XML file called USER_QOS_PROFILES.xml in the directory where you are running from, then it gets automatically loaded by the DDS application. 

You can also use other ways to tell the application where to get the XML from. Here more informations: Chapter 17 Configuring QoS with XML

Let me know if I answered to your question.

Best,
  Gianpiero

Hi Rafael, 

about editing $NDDSHOME/resource/qos_profiles_5.0.x/xml/NDDS_QOS_PROFILES.xml: i personally prefern not to do that since it will be applied to all the DDS application you run from that moment on. I usually use one of the other way explained here (i like setting the environment variable or using the USER_QOS_PROFILE in the working directory). 

I use a trick to be sure that the right XML has been loaded: put a syntax error in it :) for example do not close a tag correctly and you will see a parsing error when RTI Connext is trying to load it. 

RTI entities have to "match" to be able to comunicate. Be sure that your QoS are matching. You can find more info about the Requested vs Offered Compatibility here.

Reguarding running in two computer, I am not sure why is not working... Gerardo may have more suggestions for you about that.. 

Best, 
  Gianpiero

Hello Rafael,

A few things ideas/suggestions:

(1) To avoid dealing with the shared memory issue I would try first to get the applications communicating between two different computers. Once that is working then you can look at the situation where both are on the same computer.

(2) Running between two computers I would first try to communicate between 2 RTI applications ( you can use rtiddsping and rtiddsspy) and also between 2 OpenSplice applications. This is to ensure that you are not encountering firewall issues or some other IP routing issue. Once this is working I would go for the interoperability scenario.

(3) The directory  $NDDSHOME/resource/qos_profiles_5.0.x/xml normally contains a NDDS_QOS_PROFILES.example.xml, not a NDDS_QOS_PROFILES.xml. The NDDS_QOS_PROFILES.example.xml is just for reference and it contains all the default QoS  expressed in XML. It is not intended to be edited and it is ignored by RTI DDS. 

If you create a file named NDDS_QOS_PROFILES.xml under $NDDSHOME/resource/qos_profiles_5.0.x/xml it will be read and affect the out-of-the-box QoS.  But this is not a recommended approach because it would affect all applications which is not what you normally want.  If you do, you should not copy all the QoS in the NDDS_QOS_PROFILES.example.xml, rather the  NDDS_QOS_PROFILES.xml should only contain whatever you want to be different from these defaults...

The recommended approach is to place a  USER_QOS_PROFILES.xml file in the dirctory where you run the application from, so only applications that are run from that directory are affected.

Note that the presence of the USER_QOS_PROFILES.xml by itself does not necessarily impact the QoS of the applications that run. For that to happen you have to either set the is_default_qos="true" attribute in one of the QoS Profiles defined in USER_QOS_PROFILES.xml or else explicitly set a named QoS as default from inside your application.

(4) A RELIABLE publisher will communicate with a BEST_EFFORT subscriber. So I do not think that woud be the problem. Note that the inverse is not true. A BEST_EFFORT publisher will not communicate with a RELIABLE subscriber.

(5) A TRANSIENT publisher will communicate with a VOLATILE subscriber. The inverse is not true: A VOLATILE publisher will not communicate with a TRANSIENT subscriber.

(6) The source ports do not matter. This is not the source of the problem.

(7) What version of OpenSplice are you using? I know some earlier versions had problems in their implementation of the RTPS2 protocol.

I hope these suggestions help narrow down the issue.  We just did an interoperability demo at the OMG meeting last week so I know interoperability works at least with the configuration and version of the OpenSplice product that PrismTech brought to the demo.

Gerardo

Hi Rafael,

You can definitely set the Qos parameters in code for RTI DDS. It is part of the DDS API and we fully support it. Can you provide an snippet of the QoS setting code that does not work for you? 

For example. This snippet show how to modify in code the QoS policies used to create a DataReader:

    DDS_DataReaderQos drQos;
    subscriber->get_default_datareader_qos(drQos);
    drQos.durability.kind = DDS_TRANSIENT_LOCAL_DURABILITY_QOS;
    drQos.reliability.kind = DDS_RELIABLE_RELIABILITY_QOS;
    reader = subscriber->create_datareader(
        topic, drQos, reader_listener,
        DDS_STATUS_MASK_ALL);

The setting for other Entities (DomainParticipant, Topic, Publisher, Subscriber, DataWriter) uses the same pattern using the proper get_default_xxx_qos() in the appropriate factory for the entity.

You can also modify the Qos of an already running entity using the set_qos() operation on the entity. But bear in mind that certain policies are immutable and can only be set prior to creating (or initializing) the entity.  The pattern to use is:

    DDS_DataReaderQos drQos;
    reader->get_qos(drQos);
    drQos.durability.kind = DDS_TRANSIENT_LOCAL_DURABILITY_QOS;
    drQos.reliability.kind = DDS_RELIABLE_RELIABILITY_QOS;
    reader->set_qos(drQos);

Does it fail with RTI when you create the entity or when you change the QoS later on?  Most likely if the creation fails it is because you have specified an Inconsistent QoS setting, if during modification with a set_qos the most likely reason is either an Inconsistent QoS or an attempt to modify an immutable QoS. Either way you should see some kind of log message...

If RTI <-> RTI and OpenSplice <-> OpenSplice each work, then if points to some interoperability or QoS setting problem.  The version of OpenSplice seems fairly recent. I would assume it interoperates correctly.  But I might try testing the most basic scnarios first. For example all default QoS or all default QoS except setting the reliability policy to BEST_EFFORT to see if you can get at least the most basic scenario to interoperate.

If you are using their Communty Edition it may be a good idea to check with PrismTech because I know that some of their Community versions were not interoperable in several of the QoS scenarios.  When they participated in the Interoperability scenarios sometmes they used their Commercial version and sometimes their Open Source and this was not always fully disclosed. There were also some RTPS Extension messages that were not being properly ignored by OpenSplice causing interoperability problems... Are you seeing any indications of errors printed by OpenSplice?

Gerardo

When unsetting SHMEM transport in the transport_builtin/mask element, you should also set the ignore_loopback_interface property to false in the same participant_qos:

<element>
    <name>dds.transport.UDPv4.builtin.ignore_loopback_interface</name>
    <value>0</value>
</element>


Default for this property is 1 (true).  With this property set to 0 (false), DomainParticipants will no longer ignore the loopback and so will see other DomainParticipants on the same host.

Hi Rip,

I think setting this option explicitly is unnecessary because the deault setting of "-1" means that the system will do this automatically when the shared memory transport is disabled. 

This was documented in the previous versios of the product. See: NDDS_Transport_UDPv4_Property_t::ignore_loopback_interface. Unfortunately it seems there was a bug in the HTML documentio generation for RTI Connext DDS 5.0.0 and this no longer appears in the on-line docs but it is still described in Table 15.2 of the RTI Connext DDS User's Manual.

Gerardo 

We have been running interoperability test in the past between RTI and OpenSplice successfully. We used OpenSplice 5.4 and RTI DDS 4.5.

It should work out of the box, but perhaps you are using the keyword “module” in your IDL. If that is the case, we noticed mapping of the Type Name is different in both implementations, because the use of “module” keyword:

• RTI DDS sends as DataTypeName “module::DataTypeName”, in our example, “HelloWorldData::Msg”
• OpenSplice only sends the name of the data type, that is “Msg”

Fortunately, you can solve that easily:

• For a quick example, just use an IDL without “module”.
• For a complete solution, please modify the RTI DDS generated code, search for the Type Name string, and modify it to suppress the “module::” prefix. (Or add the prefix to the openSplice generated code).

Let me know if now it works. You can email us to info@eProsima.com

Why do you need interoperability in your project?

Hi,

I think this is just a warning so I would not expect it to not prevent the applications from communicating.

As Jaime mentioned it is quite odd because we periodically run interoperability tests using several scenarios and they are all working as far a I could see. One more thing you may try is running the RTI and PrimsTech  "shapes demo" that we used at one of the recent interoperability demos and verify you can get them to work on your setup.  If they interoperate you can look at the packet captures and perhaps get some more insight from that.

The links to the Dropbox folder containing those shapes demos are here. They are built for Linux:

RTI: https://www.dropbox.com/sh/uvzdnzajwdlyl9q/pJbykx7wG0

PrismTech: https://www.dropbox.com/sh/9993hu470npl7jf/M237FXcJBB

I am curious regarding your statement about one solution being better for larger systems and the other being more portable. As far as I know RTI is better at larger systems and also supports a far larger set of platforms... :)   Can you share more of your insights on this matter. I definitely would like to understand and learn from your perspective!

Gerardo