Why Would Anyone Use DDS Over ZeroMQ? Reply

zeroMQ vs AMQP vs DDS

Choices, choices, choices. We know you have many when it comes to your communications, messaging and integration platforms. A little over a year ago, someone asked a great question on StackOverflow: why would anyone use DDS over ZeroMQ?. In their words, “it seems that there is no benefit [to] using DDS instead of ZeroMQ.”

It’s an important question – one that we believe you should have the answer to, and so our CTO, Gerardo Pardo-Castellote, provided an answer on StackOverflow (a shorter version of his answer is provided below).

++++

In my (admittedly, biased) experience as a DDS implementer/vendor, I have found that many developers of applications find significant benefits using DDS over other middleware technologies including ZeroMQ. In fact, I see many more “critical applications” using DDS than ZeroMQ.

First a couple of clarifications:

DDS, and the RTPS protocol it uses underneath, are standards, not specific products.

There are many implementations of these standards. To my knowledge, there are at least nine different companies that have independent products and codebases that implement these standards. It does not make sense to talk about the “performance” of DDS versus ZeroMQ, you can only talk about the performance of a specific implementation. I will address the issue of performance later but from that point of view alone the statement “the latency of ZeroMQ is better” is plainly wrong. The opposite statement would be just as wrong, of course.

When is it better to use DDS?

It is difficult to provide a short/objective answer to a question as broad as this. I am sure ZeroMQ is a good product and many people are happy using it. The same can be said about DDS. I think the best thing to do is point at some of the differences and let people decide what is important to them.

DDS and ZeroMQ are different in terms of the governance, ecosystem, capabilities, and even layer of abstraction. Some important differences:

Governance, Standards and Ecosystem

Both DDS and RTPS are open international standards from the Object Management Group (OMG). ZeroMQ is a “loose structure controlled by its contributors.” This means that with DDS there is open governance and clear OMG processes that control the specification and its evolution, as well as the IPR rules.

ZeroMQ IPR is less clear. On the web page (http://zeromq.org/docs:features), it is stated that “ZeroMQ’s libzmq core is owned by its contributors” and “The ZeroMQ organization is a loose confederation without a clear power structure, that mostly lives on GitHub. The organization’s Wiki page explains how anyone can join the Owners’ team simply by bringing in some interesting work.”

This “loose structure” may be more problematic to users that care about things like IPR pedigree, Warranty and indemnification.

Related to that, if I understood correctly, there is only one core ZeroMQ implementation (the one in GitHub), and only one company that stands behind it (iMatix). Besides that, it seems just four committers are doing most of the development work in the core (libzmq). If iMatix was to be acquired or decided to change its business model, or the main committers lost interest, the user’s only recourse would be supporting the codebase themselves.

Of course, there are many successful projects/technologies based on common ownership of the code. On the other hand, having an ecosystem of companies competing with independent products, codebases, and business models provides users with assurance regarding the future of the technology. It all depends on how big the communities and ecosystems are and how risk-averse the user is.

Features and Layer of Abstraction

Both DDS and ZeroMQ support patterns like publish-subscribe and Request-Reply (a new addition to DDS, the so-called DDS-RPC). But generally speaking, the layer of abstraction of DDS is higher. Meaning the middleware does more “automatically” for the application. Specifically:

DDS provides for automatic discovery

In DDS you just publish/subscribe to topic names. You never have to provide IP addresses, computer names or ports. It is all handled by the built-in discovery. And it does it automatically without additional services. This means that applications can be re-deployed and integrated without recompilation or reconfiguration. 

In comparison, ZeroMQ is lower level. You must specify ports, IP addresses, etc.

DDS pub-sub is data-centric

An application can publish to a Topic, but the associated data can represent updates to multiple data-objects, each identified by key-attributes. For example, when publishing airplane positions each update can identify the “airplane ID” and the middleware can provide history, enforce QoS, update rates, etc. for each airplane separately. The middleware understands and communicates when new airplanes appear or disappear from the system.

Also, DDS can keep a cache of relevant data for the application, which it can query (by key or content) as it sees fit, e.g., read the last 5 positions of an airplane. The application is notified of changes but it is not forced to consume them immediately. This also can help reduce the amount of code the application developer needs to write.

DDS provides more support for “application” QoS

DDS supports over 22 message and data-delivery QoS policies, such as Reliability, Endpoint Liveliness, Message Persistence and delivery to late-joiners, Message expiration, Failover, monitoring of periodic updates, time-based filtering and ordering. This is all configured via simple QoS-policy settings. The application uses the same read/write API and all the extra work is done underneath.

ZeroMQ approaches this problem by providing building blocks and patterns. It is quite flexible but the application has to program, assemble and orchestrate the different patterns to get the higher-level behavior. For example, to get reliable pub-sub requires combining multiple patterns as described in http://zguide.zeromq.org/page:all#toc119.

DDS supports additional capabilities like content-filtering, time-filtering, partitions, domains and more

These are not available in ZeroMQ. They would have to be built at the application layer.

DDS provides a type system and supports type extensibility and mutability

You have to combine ZeroMQ with other packages like Google protocol buffers to get similar functionality.

Security

There is a DDS-Security specification that provides fine-grained (Topic-level) security including authentication, encryption, signing, key distribution and secure multicast.

How does the performance of DDS compare with ZeroMQ?

Note that you cannot use the benchmarks of Object Computing Inc.’s “OpenDDS” implementation for comparison. As far as I know, this is not known to be one of the fastest DDS implementations. I would recommend you take a look at some of the other implementations such as RTI Connext DDS (our implementation), PrismTech’s OpenSplice DDS or TwinOaks’ CoreDX DDS. Of course, results are highly dependable on the actual test, network and computers used, but typical latency performances for the faster DDS implementations using C++ are on the order of 50 microseconds, not 180 microseconds of OpenDDS. See https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY

Middleware layers like DDS or ZeroMQ run on top of things like UDP or TCP, so I would expect they are bound by what the underlying network can do and for simple cases they are likely not too different, and they will, of course, be worse than the raw transport.

Differences also come from what services they provide. So you should compare what you can get for the same level of service, for example publishing reliably to scaling to many consumers, prioritizing information and sending multiple flows and large data over UDP (to avoid TCP’s head-of-line blocking).

Based on the relative performance of different DDS implementations  (http://www.dre.vanderbilt.edu/DDS/), I would expect that in an apples-to-apples test, the better-performing implementations of DDS would match or exceed ZeroMQ’s performance.

That said, people rarely select the middleware that gives them the “best performance.” Otherwise, no one would use Web Services or HTTP. The selection is based on many factors; performance just needs to be as good as required to meet the needs of the application. Robustness, scalability, support, risk, maintainability, the fitness of the programming model to the domain and total cost of ownership are typically more important to making the correct decision.

Which one is best?

If you’re still undecided, or simply want more information to help you in making a decision, you’re in luck! We have the perfect blog post for you: 6 Industrial IoT Communication Solutions – Which One’s for You? [Comparison].

If you think RTI Connext DDS may be what you need, head on over to our Getting Started homepage where you’ll find a virtual treasure trove of resources to get you up and running with Connext DDS.

getting started with connext dds

We’re heading to Munich! Reply

events-hero-background (1)

London Connext Conference 2014 and 2015 events brought power DDS users together from a wide range of industries to share experiences, applications and expertise. For those of you who were unable to attend but curious about what you missed, head over to Community and view a list of the presenters and some of the presentations (2014 and 2015). For our third year, we wanted to switch things up a bit, and the first big change to the event is the location: we’ll be hosting our two-day event in Munich!

The second change (and the one I’m most excited to announce) relates to our agenda. In the past, we’ve created an agenda that showcases our users and their work through a curated selection of keynote presentations, demonstrations, and smaller group presentations. This year, in addition to these, we’re going to be offering 2 workshops! The first workshop focuses on using Connext Pro Tools and the other will dive into Connext DDS Secure. During these workshops, you’ll have time to get up and running with the products, ask questions and receive answers from RTI staff, and more.

This is just a sampling of what we’ll be offering. To register now, head on over to https://www.rti.com/munich-connext-con-2017. Also, if you’ll be attending and would like to be considered for a keynote spot at this year’s conference, please visit the conference page for submission details. We can’t wait to see you there!

Getting Started with Connext DDS – ELI5, please. Reply

GettingStartedBlog

One of my favorite subreddits is r/ELI5. For those of you who might not know, ELI5 is a forum, dedicated to offering up explanations of user-submitted topics and concepts in a very specific way – explaining it in a way that even a 5-year old would understand, hence ELI5 (Explain it Like I’m 5).

ELI5 is a pretty popular subreddit. Why? Well, I believe it’s because there are tons of things we don’t know much about (we’re all experts in one area or another, but we don’t know everything!), and these posts give us a chance to gain some basic knowledge outside our area of expertise. Making information simple benefits everyone. Simplicity doesn’t mean a lack of complexity. Being able to take a complex subject that you’ve spent years immersed in, and distil it down to some facts and anecdotes that provide a level of working understanding is amazing – it makes information accessible.

ELI5 doesn’t mean the thing you’re describing isn’t interesting, valuable or worthy of more time and attention. Being able to ELI5 allows people with little to no domain knowledge or context on these more complex and nuanced subjects to understand the basics and to incorporate those basics into other things. It’s general, but it’s useful. If you can give a 5-year old a working understanding of things such as what is a product?, why do we have a president?, or what is middleware?, you really have to understand what you’re talking about.

From my perspective, DDS is powerful – and can be complex – and we hope we’ve made it accessible enough that you can do amazing things with it.

At RTI, we’ve been working behind the scenes to bring you something new. In the spirit of my favorite subreddit, I want to introduce you to Getting Started – all the tools and information you need to get started with DDS.

We explain how to use our products, how to go from install to helloworld, what DDS is (whitepapers), how people are using it, how you can setup the basics using our full sets of configuration files and code to address your most common and challenging use cases (case+code) and more. We’ve even curated special collections of content to meet your needs so you don’t have to wade through everything. And this is only phase 1 – we have so much more information that’s just waiting to go live, and we’re excited to share it.

Ready to take the leap? Check out the first step! Installation for Linux or Windows, take your pick!

And as part of making sure you’re getting what you need, let us know. What would you find valuable to get up and running using DDS? What questions did you need answers to, but had trouble finding? What content did you wish was available that wasn’t when you first started using our product? Tell us or leave a comment!