Open DDS vs. RTI Connext Software

When building any software system, choosing between fully custom “Roll Your Own” (RYO), open source software (OSS) and closed source (Commercial) software is a challenging decision. While there are many factors to consider in designing distributed network applications, this article will focus on those relating to the communications framework that forms the nervous system of many complex, real-time applications. The assumption is that you’ll use RYO software for your custom application features and leverage existing components where possible.

The Object Management Group (OMG^®) Data Distribution Service (DDS™) standard is an "open standard." The standard is publicly available and provides a normative reference to help guarantee consistency, portability and interoperability. An open standard is not the same as software that is "open source." OSS is computer software made available with its source code. OSS may be shared, modified and distributed, under some open source license. DDS is an open standard and has both Commercial and OSS implementations available. For example, OpenDDS is an OSS implementation managed by OCI (Object Computing Inc.). There are many commercial distributions available as well, the most deployed in mission critical systems being RTI Connext. 

So, what factors should you consider when deciding between an OSS versus a Commercial DDS solution?

Open Source DDS Core Features

First, it is important to examine the DDS features you need. If you aren't certain of what you will need, a complete implementation is more likely to meet your needs over time. Here are some of the standard OMG DDS capabilities that Connext supports which are not commonly found in OSS DDS distributions:

• Language support – Connext supports ANSI C, C++03, C++11, Java, Ada, Python, C#/.Net. As an example, OpenDDS only supports traditional C++.  Just as DDS allows different parts of your system to use different hardware architectures and even operating systems, the flexibility of multiple language support can get you to market faster.
• Writer-side content filtering – uses less bandwidth and fewer CPU cycles on the receiver side
• Data types definition via extensible DDS-XTypes™ – defines data types flexibly with the ability to evolve without giving up portability, interoperability or the expressiveness of the DDS type system
• Request/Reply functionality – part of the OMG standard providing an additional messaging paradigm
• XML Application Language specification support – provides users with Quality of Service (QoS) configuration through XML files, so behavior can be changed without recompiling
• Coherent data across multiple Topics – a sophisticated design pattern for coherent sets with presentation access scope

Additionally, here are some of the enhanced (non-standard) capabilities that Connext supports which are not commonly found in OSS DDS:

• Guaranteed delivery features – "application-level" acknowledgments, virtual GUIDs (to support redundant routing services), durable subscriptions and writer history, asynchronous publishing and collaborative datawriters
• Batching – Combine smaller packets into a larger packet for greater throughput. 
• Topic Query – Query historical data from your Topics.
• IP Mobility – Dynamically add, remove and change IP connections.

Application Components and Services

When considering solutions, it's important to determine what support outside the DDS core you may need. Do you need to interface with web pages? Do you want to persist data in the event of power-down? Some of the key services not available with OSS DDS include:

• Routing Service – Forward and transform data between DDS domains.
• Record and Replay Service – Record data at high speeds. Replay to a live or simulated system at faster/slower speeds.  Modify the saved data to create corner-case scenarios for validation.
• Web Integration Service – Develop web-based and browser-based applications. Read and write DDS data using only HTTP commands. Even dynamically create DDS Entities using REST or WebSockets (WS) following the DDS-Web OMG Specification. Do it all securely with HTTPS or WSS.
• Persistence Service – Store data permanently and make it available to applications whenever they join the system.
• System Designer – Graphically design and configure Connext systems with help from AI trained on Connext.
• Cloud Discovery Service and Real-Time WAN – Deploy DDS in the cloud, navigating firewalls  and extending the databus via the public internet.
• Container Integration – Start with pre-built Docker packages and leverage Containers for deployment.

Tools for DDS Implementation

What development tools are available for the DDS implementation you are considering? Often DDS is used in large inter-connected systems that can be quite complex. Having the right tools available to debug these systems is crucial. Connext has a complete set of tools designed to meet the needs of real customers over 20 years, including:

• Admin Console – View running DDS applications and visualize the data. See the participants, topics, writers, and readers including QOS settings and data-types.  Connection problems are automatically identified.
• Monitoring / Observability Framework – A next-gen monitoring tool that will collect communications data and drive Grafana Dashboards with detailed DDS statistics such as packet counts or Liveliness status.
• rtiddsspy – A command line utility to view DDS traffic without a GUI.
• Heap Analysis Tool – Take snapshots of DDS heap usage and quickly identify memory leaks.
• CodeGenerator – Generate type support code and working examples from an IDL or XML description of your datatypes according to the matching OMG specification.

DDS Security

OSS DDS distributions do not directly include any security support. That is, most do not support the DDS Security standard and also do not have any TLS or DTLS transports available. Connext supports the DDS Security standard and also has a Secure WAN transport that includes TLS and DTLS support.

Robustness

Robustness is perhaps the most important factor when determining if a particular OSS DDS implementation is a good choice. The best way for software to prove itself is in actual customer applications. How many real-world, deployed systems are using the DDS implementation you are considering? Connext has been field-tested, proven and used by more than 2,000 different projects in over 1 million devices today. Some of these complex, mission-critical applications, that leverage Connext today, include:

• Moon Surgical – surpassing 1,000 treated patients worldwide
• Mevion Medical Systems – managing thousands of parameters that control the aim and duration of the 250 mega-electron volt proton beam
• Raytheon – connecting hundreds of computers, 1,500 teams building thousands of applications, and more than 10M publish-subscribe pairs

Connext has proven itself repeatedly in mission-critical, real-world applications. This includes extensive automated testing, rigorous training and reviews, and extensive issue tracking and management. In addition, the RTI Testing Lab is one of the industry’s largest, most complete lab facilities, able to test over 3,000 endpoints and over 100 different targets, validating Connext on: 

• 1,600 Cores
• Over 300 embedded boards
• 25 Operating systems
• Many different network types 

A very important question to ask yourself is: What is the quality of the DDS implementation that you are entrusting your products to?

Non-Functional Aspects

There are a few other items to consider. Commercial software typically has a published release cadence along with a tiered support and extended support period. This helps you manage your schedules and release milestones. A stable release cadence is also part of a Vulnerabilities Mitigation strategy. A software product with a definitive release date can have a well-planned strategy for handling the inevitable Vulnerability patch(es) needed. OSS often uses a chaotic release strategy which causes duplicate testing and impacts product schedules.

Costs

Some OSS DDS implementations are available as a free download, appearing initially to cost less than a Commercial DDS. However, over time, the costs of using OSS DDS can increase. While OSS DDS is supported by an open source community without license, support or runtime fees, you must rely on community support or pay another company for support. As a result, OSS DDS will likely cost more in the long run due to missing features, the extra developers that are needed, increased development time and additional support costs. How much of staff’s time will go towards your product deliverables vs. community participation? What is the value of avoiding a bug because you’re using stable, battle-tested, well-crafted software? How important is fast, reliable support? Weigh the cost of a Commercial DDS license versus the loaded cost of an engineer per year. Is it worth it to “save” the money up front?

Time to Market

How quickly do you need to get your product to market? If the DDS implementation you want to use is less complete – does not have the tools, documentation, support or services you need, or just does not work as expected – how is that going to affect your schedules? How important is getting your product out on time with all the envisioned functionality?

Generally speaking, Commercial DDS implementations are more full-featured and more robust than OSS versions. This is because they have a larger number of engineers dedicated full-time to development and testing. For instance, Connext Professional has over 50 engineers working full time on development. This does not include the 25 full-time support engineers, or the services, training and field application engineers.

DDS Support

It is critical to understand what support is available to you in case you run into problems. OSS DDS usually has support available through online user groups or third parties for a fee. However, you’ll want to determine if the support engineers are dedicated to just this implementation or if they support multiple products. Also, do they have an escalation policy if you run into critical problems? Will the only fix require a migration to a different fork?

RTI understands that connectivity software is a mission-critical part of your application and treats customer support seriously. Our support engineers are exceptionally qualified: They are experts at designing, debugging and implementing distributed real-time and embedded systems. With global support centers, RTI support engineers can be reached almost 24/7. In addition, RTI support engineers are co-located with, and have direct access to, development engineering resources. It is imperative to have the development engineers help out when a critical issue has stalled your project’s progress.

RTI has examples available online for many Connext features. There are also user group articles, instructional videos, blogs, Case + Code walkthroughs, online training and over 2,000 pages of documentation. With the rollout of the Connext AI Chatbot in April of 2025, trained specifically on Connext, you’ll join 3,000+ users getting not only great answers with clickable references but even unique, validated sample code or QoS snippets, anytime.

Get Started With RTI Connext 

It is important that you completely understand your requirements and what features and services you need before selecting which DDS implementation to use. The following are some of the key questions to help define your requirements:

• Are the languages that you want to use supported?
• Are there QoS settings which support your requirements?
• Do you need integration with the cloud? Will you need security in the future? Or certification?
• Is the release robust? Does it go through rigorous testing? Has it been successfully used numerous times in fielded applications?
• What about future requirements? Easily leveraging existing design patterns like Request/Reply, RPC, Asynchronous Publication and Redundancy can help ensure your Application is successful. 
• What will the costs be, measured in dollars, or time or risk, with having to change to a different DDS implementation to go to market?

If you have a complex product with time-to-market concerns that needs to be rock solid, well supported, with the features you need now and in the future, then RTI Connext is the right choice.

Learn more:

The True Cost of Open Source in Mission-Critical Applications

What's New in Connext »

About the authors: 

Andy Krassowski is a Senior Field Application Engineer for Real-Time Innovations, supporting customers in the eastern US area. Andy has been in the real-time software industry for over 40 years working in engineering and sales roles.  Andy holds a Bachelor of Science degree in electrical engineering from Worcester Polytechnic Institute, and a Master of Science degree in computer science from the Rensselaer Polytechnic Institute.

Dave Seltz is a Field Application Engineering Manager for Real-Time Innovations supporting customers in the eastern US area. Dave has been in the embedded industry for over 32 years working in engineering and sales roles.  Previous to his work at RTI, Dave was the world-wide FAE manager for Wind River Systems. He holds a Bachelor of Science degree in computer engineering from Lehigh University, and a Master of Science degree in computer engineering from the University of Massachusetts.