问题描述
我阅读以下内容：
- DDS vs AMQP vs ZeroMQ
- http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html
并且似乎没有使用DDS代替zmq的好处：
And it seems that there is no benfit using DDS instead of zmq:
- zmq的延迟更好。
- 在我看来ZMQ的API已清除且简单。
- 我不能使用ZMQ来在线程/进程/站之间传输数据。
所以：
- 何时使用DDS更好？
- 与ZMQ相比，DDS是否有更好的性能？
- 使用DDS（而不是ZMQ）是否有明确的目的？
- When it is better to use DDS ?
- Are there any better performance of DDS over ZMQ ?
- Is there a clear purpose of using DDS (and not ZMQ) ?
谢谢
推荐答案
在我作为DDS实现者/供应商的经历中（有偏见），许多应用程序发现使用DDS优于中间件技术（包括ZeroMQ）的显着优势。实际上，我看到使用DDS的关键应用程序比ZeroMQ还要多。
In my (admittedly biased) experience as a DDS implementor/vendor many applications find significant benefits of using DDS over middleware technologies, including ZeroMQ. In fact I see many more "critical applications" using DDS than ZeroMQ...
首先要澄清一下：
（1）DDS及其下面使用的RTPS协议是标准而非特定产品。这些标准有许多实现。据我所知，至少有9家不同的公司拥有实现这些标准的独立产品和代码库。谈论DDS与ZeroMQ的性能是没有意义的，您只能谈论特定实现的性能。稍后我将讨论性能问题，但仅从这种观点来看，您的 zmq的延迟更好的说法显然是错误的。当然，相反的说法也一样。
(1) 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 9 different companies that have independent products and codebases that implement these standards. It does not make sense to talk about the "performance" of DDS vs 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 your statement "the latency of zmq is better" is plainly wrong. The opposite statement would be just as wrong, of course.
（2）在您提供的第一个参考文献中，我没有发现太多客观信息。最主要的一点是，DDS似乎最适合该应用程序，并且它的使用范围也令人担忧，AC的答复对此予以澄清。但是论点似乎有些主观。基于某人对特定产品代码库的主观检查，AC的帖子遭到否定的回复。即使假设发布负面评论的人有一个正确的论点，这些评论也仅适用于一个特定的DDS实施/产品，而不适用于一般的DDS。就我个人而言，我不会对此评论给予太大的信任，它的语气似乎过于敌对，无法仅基于陈述的事实。
(2) I did not find much objective information in first reference you provided. The main point there was that DDS seemed the best fit for that application and there was a concern about how broadly it was used, which the reply from AC clarified. But the arguments seemed a bit subjective. There was a negative reply to AC's posting based on somebody's subjective examination of the codebase of a specific product. Even assuming the person that posted the negative comments had a valid point, the comments would apply only to one specific DDS implementation/product not to DDS in general. Personally I would not give much credence to that comment, its tone seems too hostile to be based on just the stated facts.
（3）关于API的清晰度/简洁性。您的评论是否基于第二参考中提供的基准示例？此代码未使用标准DDS API。我不确定为什么OCI（写这篇文章的公司）会那样做-也许他们改编了其他一些先前的代码。
(3) Regarding the clarity/simplicity of API's. Are your comments based on benchmark example you provide in the second reference? This code is not using the standard DDS APIs. I am not sure why OCI (the company that wrote that article) did it like that--perhaps they adapted some other prior code.
查看符合DDS规范的API示例的好地方是：
A good place to look at API examples that are conformant with the DDS specification are these:
- 现代C ++：
- 经典C ++：
- Modern C++: http://blogs.rti.com/2014/08/01/create-a-p2p-distributed-application-in-under-35-lines-of-c11-code/
- Classic C++: http://www.twinoakscomputing.com/coredx/examples/hello_cpp
无论如何，正如我稍后提到的那样，DDS和ZeroMQ提供的抽象层是完全不同的，因此API是不能直接比较...
In any case as I mention later the layer of abstraction provided by DDS and ZeroMQ is quite different so the APIs are not directly comparable...
为您解答特定问题。
1。何时使用DDS更好？
很难对如此广泛的问题提供简短/客观的答案。我确信ZeroMQ是一个很好的产品，很多人都很高兴。关于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. 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和ZeroMQ在治理，生态系统，功能甚至抽象层方面都不同。
DDS and ZeroMQ are different in terms of the governance, ecosystem, capabilities, and even layer of abstraction.
一些重要差异：
1.1治理，标准与规范生态系统
DDS和RTPS是对象管理小组（OMG）的开放国际标准。 ZeroMQ是由其贡献者控制的松散结构
DDS and RTPS are open international standards from the Object Management Group (OMG). ZeroMQ is a "loose structure controlled by its contributors"
这意味着存在开放的治理和清晰的OMG流程，可控制规范及其演变以及IPR规则。
This means there is open governance and clear OMG processes that control the specification and its evolution, as well as the IPR rules.
IMO不太清楚ZeroMQ IPR。在他们的网页（上）中，他们指出 ZeroMQ的libzmq核心归其贡献者所有和 ZeroMQ组织是一个松散的联盟，没有明确的权力结构，通常存在于GitHub上。组织Wiki页面说明了任何人都可以通过引入一些有趣的工作来加入所有者团队。
ZeroMQ IPR is less clear IMO. From their web page (http://zeromq.org/docs:features) they state "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 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, etc.
与此有关。如果我理解正确，那么只有一个核心ZeroMQ实现（github中的实现），只有支持它的公司（iMatix）。从那里开始，似乎只有4个提交者在核心（libzmq）中完成大部分开发工作。如果要收购iMatix或决定改变其商业模式，或者主要提交者失去兴趣，那么用户将只能依靠自己支持代码库而无所适从。
Related to that. if I understood correctly there is only one core ZeroMQ implementation (the one in github), and only company that stands behind it (iMatix). From there it seems just 4 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 users would few recourse beyond 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 good assurance to the future of the technology... It all depends how big the communities and ecosystems are and how risk-averse the user is.
1.2功能&抽象层
DDS和ZeroMQ支持两种模式，例如发布-订阅和请求-答复（这是DDS的新增功能，即所谓的DDS -RPC）。但是总的来说，DDS的抽象层更高。意味着中间件为应用程序提供了更多自动功能。
Both DDS and ZeroMQ support patterns like publish-subscribe and Request-Reply (this is 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提供自动发现
在DDS中，您只需发布/订阅主题名称。您无需提供IP地址，计算机名称或端口。全部由内置发现处理。而且它会自动执行而无需其他服务。这意味着可以重新部署和集成应用程序，而无需重新编译或重新配置。
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 builtin discovery. And it does it automatically without additional services. This means that applications can be re-deployed and integrated without recompilation or reconfiguration.
ZeroMQ的级别较低。您必须指定端口，IP地址等。
ZeroMQ is lower level. You must specify ports, IP addresses etc.
DDS pub-sub以数据为中心。
应用程序可以发布到主题，但关联的数据可以表示已更新为多个数据对象，每个数据对象均由键属性标识。例如，当发布飞机位置时，每个更新都可以标识飞机ID，并且中间件可以分别提供历史记录，强制执行QoS，更新速率等。当新飞机出现或从系统中消失时，中间件可以理解并进行通信。
An application can publish to a Topic, but the associated data can represent updated 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.
与上述DDS相关的内容可以为应用程序保留相关数据的缓存，它可以根据需要查询（按键或内容），例如读取飞机的最后5个位置。通知应用程序更改，但不强制立即使用它们。这也可以帮助减少应用程序开发人员需要编写的代码量。
Related to the above 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为应用程序 QoS提供了更多支持
DDS支持22种以上的消息和数据传递QoS策略，例如可靠性，端点活动性，消息持久性和向后连接者的传递，消息到期，故障转移，定期更新监视，基于时间的过滤，排序等。所有这些都通过简单的QoS策略设置进行配置。该应用程序使用相同的读/写API，并在下面完成所有其他工作。
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, ordering, etc. This are all configured via simple QoS-policy settings. The application uses the same read/write API and all the extra work is done underneath.
ZeroMQ通过提供构造块和模式来解决此问题。它非常灵活，但是应用程序必须对不同的模式进行编程，组装和编排以获得更高级别的行为。例如，要获得可靠的发布订阅，需要组合多种模式，如。
ZeroMQ approaches this problem by providing building blocks and patters. 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支持其他功能，例如内容过滤，时间过滤，分区，域，...
这些在ZeroMQ中不可用。它们必须在应用程序层构建。
These are not available in ZeroMQ. They would have to be built at the application layer.
DDS提供类型系统并支持类型可扩展性和可变性
您必须将ZeroMQ与其他包（例如Google协议缓冲区）结合使用才能获得类似的功能。
You have to combine ZeroMQ with other packages like google protocol buffers to get similar functionality.
安全性
有一个DDS安全规范，可提供细粒度（主题级）安全性，包括身份验证，加密，签名，密钥分发，安全多播等。
There is a DDS-Security specification that provides fine-grained (Topic-level) security including authentication, encryption, signing, key distribution, secure multicast, etc.
2。 DDS是否比ZMQ有更好的性能？
请注意，您所指的基准是针对Object Computing Inc的 OpenDDS实现的。据我所知，这不是最快的DDS实现之一。我建议您看看RTI Connext DDS（我们的实现），PrimsTech的OpenSplice DDS或TwinOaks的CoreDX DDS等其他产品。当然，结果在很大程度上取决于所使用的实际测试，网络和计算机，但是使用C ++实现更快的DDS实现的典型延迟性能大约为50微秒，而不是180微秒。参见
Note that the benchmarks you refer to are for Object Computing Inc's "OpenDDS" implementation. 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 ones like RTI Connext DDS (our implementation), PrimsTech'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). See https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY
中间件层（例如DDS或ZeroMQ）运行在UDP或TCP之类的东西之上，因此我希望它们受底层网络的能力和简单情况的约束。它们之间的差异可能不会太大，并且它们当然会比原始运输更差。
Middleware layers like DDS or ZeroMQ run on top of a 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.
差异还取决于它们提供的服务。因此，您应该比较在相同服务水平下可以获得的收益，例如可靠地发布以扩展到许多使用者，确定信息的优先级，通过UDP发送多个流和大数据（以避免TCP的行头阻塞）等。
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, sending multiple flows and large data over UDP (to avoid TCP's head-of-line blocking), etc.
根据您参考的OpenDDS研究以及不同DDS实现的相对性能（），我希望在一次苹果到苹果的测试中，性能更好的DDS实现将匹配或超过ZeroMQ。
Based on the OpenDDS study you reference, and 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.
这表示人们很少选择能给他们最佳性能的中间件。否则，没人会使用Web服务或HTTP。该选择基于许多因素，性能只需要与满足应用程序需求一样好即可。健壮性，可伸缩性，支持性，风险性，可维护性，编程模型对域的适用性，总拥有成本等通常对于决策而言更为重要。
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, fitness of the programming model to the domain, total cost of ownership, etc. are typically more important to the decision.
3。使用DDS（而不是ZMQ）有明确的目的吗？
嗯，是的，在许多应用中，它提供了以下方面的最佳权衡：性能，可伸缩性，功能，应用程序简单性，健壮性，降低风险和总拥有成本。在过去的几年中，成千上万的项目得出了这样的结论：）
Well, yes... in many applications it provides the best tradeoff in terms of performance, scalability, features, application simplicity, robustness, risk-reduction, and total cost of ownership. In the last few years thousands of projects came to that conclusion :)
Gerardo
这篇关于为什么/何时使用DDS代替ZeroMQ？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！