Questions about getting started with CycloneDDS

[skysky97]

After trying CycloneDDS for a few days, I had some questions about it. Please help.

1. Do we have a feature list for released version or master branch. The roadmap hasn't been updated for a while. Does v0.8 fully support DDS-RTPS.
2. What are the advantages of CycloneDDS compared with other DDS implementations like FastDDS. I didn't find too much information on website. The biggest difference I know is that CycloneDDS is written in C and maybe good for embedded applications.

[eboasson]

Do we have a feature list for released version or master branch. The roadmap hasn't been updated for a while. Does v0.8 fully support DDS-RTPS.

Good question, I don’t think there’s a proper feature list, but to a very good approximation it is:

• DCPS Minimum profile
• DCPS Ownership profile
• DCPS Content profile, except that it takes a pointer to a function from a sample to a boolean
• DDS Security authentication, access control and encryption
• DDS C++ API

With version 0.9.0 (planned release date is 2022-03-28, so just a few more days) it adds:

• DDS XTypes except for the C/C++ dynamic API because that’s covered in a much nicer way by our Python API

Cyclone DDS’s network stack has fully supported DDSI-RTPS since about 2010 and has been used in a many systems, including large, high-availability ones and systems where interoperation with other implementations was needed. So yes, it fully supports DDSI-RTPS since the initial commit.

The roadmap needs updating, yes … the areas that we are now focussing on are full support for transient/persistent data (a.k.a., the DCPS Persistence Profile) as well as full compliance with the content subscription profile (filters and queries using the standardized SQL-subset). Once that’s in there is only one major bit we need to do to fully support the entirety of DDS, which is the “group coherency” and related features.

What are the advantages of CycloneDDS compared with other DDS implementations like FastDDS. I didn't find too much information on website. The biggest difference I know is that CycloneDDS is written in C and maybe good for embedded applications.

We are working on the website, it is just that everyone involved in the project prefers to deal with the code rather than websites, roadmaps and stuff. We should probably care more about those things because not putting the effort in makes us much less visible or attractive. But you ask, so that’s a great 😊

I think it is a mistake to consider Cyclone DDS as an embedded-first implementation: it is well on its way to covering the full functionality of DDS, and the only reason we care about that is because we target all kinds and scales of systems, including embedded ones.

Regarding that “all scales”: there are of course some inherent scalability problems in the DDSI-RTPS discovery protocol if you want to use DDS in large systems. I know of systems that use this (Cyclone’s) stack in networks of 10s of machines, 100s of topics, 1000s of subscriptions, but that’s possible because it was done with some care and with few processes per machine. My employer had a product for scalable discovery without requiring tweaks to the protocol, and that’s the direction we’ll go for solving that. As far as I know, other DDS implementations tend to just hack yet-another-protocol into their stack. Easier, perhaps, but far worse a solution in the long run.

The “all kinds” is the bit that I personally find most interesting. If you look at the various implementations carefully, most tend to really focus on the boring publish-subscribe messaging, while arguing that the advantages of DDS over “competing” technologies like MQTT or ZMQ lie in its richer set of QoS settings, built-in conversion from application data to/from network representations, performance. Stuff like that.

What they tend to ignore is that DDS really aims to present the application developer with an eventually-consistent shared data space (the spec calls it “global data space”, but that is a bit too vague to my taste). There is a difference between building a distributed application using message passing, and building one by writing microservices that monitor some part of a data space and publish some derived information.

Fault-tolerant, extensible, performant control systems built using the latter philosophy have a long history, started by my father in the ‘80s. That is what DDS really comes from … The key DDS feature for this is the support for “transient data” (often used to capture desired- and actual-states of application processes as well as the real-world objects these systems model), and it is precisely this part that many DDS implementations completely ignore, or else get wrong.

As far as I know the only two implementations that take it seriously today are ZettaScale’s OpenSplice and RTI Connext. Both are commercial products, implementing essentially all of DDS, and both are burdened by a very long legacy.

Furthermore I think Cyclone is the only one open-source implementation that has a ton of language bindings on the roadmap. We currently have C, C++, Python and (thanks to @sjames) an initial Rust binding. The only reason we don’t yet have C#, Java, Haskell, Ada, Simulink is time.

Finally, unlike some of the other implementations that provide their code under fully open-source licenses, Eclipse Cyclone DDS is not owned by a company but is truly a community project, overseen by a major open-source foundation. We invite and even promote adopters in the community to contribute to the development and help set priorities and direction in public discussions. We — the current main contributors — have a vision for Cyclone DDS and we’ll do our best to realise it, hopefully jointly with whoever is interested. Like we do in our fruitful cooperation with the Eclipse Iceoryx and Eclipse Zenoh projects.

[livanov93]

@eboasson I also have a question regarding the use of cyclone DDS with ROS2.

I have one network card on my system which is used by DDS. The setup consists of many computationally expensive processes, whose results are shared on the ROS network (e.g. large messages are shared). On the other hand, I have tcp/ip communication process which has strict timing constraints. This connection keeps dropping whenever the rest of the ROS2 setup is running (lot of bandwidth is used). I am not allowed to relax timing constraints for the process, but I am interested in other solutions.

To finally conclude if it is DDS related problem, I tried setup with two network cards where the cyclone dds was using one, and the process with strict timing constraints the other one. I haven't seen it disconnected at all in this 2 network card setup.

Is there a way to isolate any communication process from the dds? I know it is possible to reduce MaxMessageSize to inherently reduce udp payload, but that won't solve my problem.

What are other tweaks that can be done to make my system work with only 1 network card?

Thanks in advance for any advice!