为什么/何时使用 DDS 而不是 ZeroMQ？
WHY / WHEN using rather DDS instead of ZeroMQ?
我阅读了以下内容：
- DDS vs AMQP vs ZeroMQ
- http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html
而且使用 DDS 代替 zmq 似乎没有任何好处:
- zmq 的延迟更好。
- 在我看来ZMQ的API清晰简单
- 我不能使用 ZMQ 在线程/进程/站之间传输数据。
所以：
- 什么时候用DDS比较好?
- DDS 是否有比 ZMQ 更好的性能？
- 使用 DDS（而不是 ZMQ）是否有明确的目的？
谢谢
根据我作为 DDS 的（诚然有偏见的）经验 implementor/vendor 许多应用程序发现使用 DDS 比使用中间件技术（包括 ZeroMQ）有显着的好处。事实上，我看到更多 "critical applications" 使用 DDS 比使用 ZeroMQ...
首先澄清几点：
(1) DDS和它下面使用的RTPS协议是标准的，不是具体的产品。这些标准有很多实现。据我所知，至少有 9 家不同的公司拥有实施这些标准的独立产品和代码库。谈DDS vs ZeroMQ的"performance"没有意义，只能谈具体实现的性能。我稍后会解决性能问题，但仅从这个角度来看，您的陈述 "the latency of zmq is better" 显然是错误的。当然，相反的说法也是错误的。
(2) 我在您提供的第一份参考资料中没有找到很多 objective 信息。主要观点是 DDS 似乎最适合该应用程序，而且人们担心它的使用范围有多广，AC 的答复对此进行了澄清。但这些论点似乎有点主观。根据某人对特定产品代码库的主观检查，AC 的帖子得到了否定答复。即使假设发布负面评论的人有一个有效的观点，这些评论也只适用于一个特定的 DDS implementation/product 而不是一般的 DDS。就我个人而言，我不太相信该评论，它的语气似乎过于敌对，无法仅基于陈述的事实。
(3) 关于API的clarity/simplicity。您的评论是否基于您在第二个参考资料中提供的基准示例？此代码未使用标准 DDS APIs。我不确定为什么 OCI（撰写该文章的公司）会那样做——也许他们改编了其他一些先前的代码。
查看符合 DDS 规范的 API 示例的好地方是这些：
- 现代 C++：http://blogs.rti.com/2014/08/01/create-a-p2p-distributed-application-in-under-35-lines-of-c11-code/
- 经典 C++：http://www.twinoakscomputing.com/coredx/examples/hello_cpp
在任何情况下，正如我稍后提到的，DDS 和 ZeroMQ 提供的抽象层是完全不同的，因此 APIs 不能直接比较...
回答您的具体问题。
1.什么时候用DDS比较好？
很难为如此宽泛的问题提供 short/objective 答案。我确信 ZeroMQ 是一个很好的产品，很多人都很高兴。 DDS 也是如此。
我认为最好的办法是指出一些差异，让人们决定什么对他们来说是重要的。
DDS 和 ZeroMQ 在治理、生态系统、功能甚至抽象层方面都不同。
一些重要的区别：
1.1 治理、标准与生态系统
DDS 和 RTPS 是对象管理组织 (OMG) 的开放国际标准。 ZeroMQ 是一个 "loose structure controlled by its contributors"
这意味着有开放的治理和清晰的 OMG 流程来控制规范及其演变，以及 IPR 规则。
ZeroMQ IPR 在我看来不太清楚。从他们的网页 (http://zeromq.org/docs:features) 他们声明 "ZeroMQ's libzmq core is owned by its contributors" 和 "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."
这个"loose structure"对于关心知识产权谱系、保修和赔偿等问题的用户来说可能会有更多问题
与此有关。如果我理解正确的话，只有一个核心 ZeroMQ 实现（github 中的那个），并且只有它背后的公司 (iMatix)。从那里看来，只有 4 个提交者在核心 (libzmq) 中完成大部分开发工作。如果 iMatix 被收购或决定改变其商业模式，或者主要提交者失去兴趣，用户除了自己支持代码库之外几乎没有其他办法。
当然有很多成功的projects/technologies基于代码的共同所有权。另一方面，拥有与独立产品、代码库和商业模式竞争的公司生态系统为技术的未来提供了良好的保证……这完全取决于社区和生态系统的规模以及用户的风险规避程度。
1.2 特征和抽象层
DDS和ZeroMQ都支持publish-subscribe和Request-Reply等模式（这是DDS的新增功能，即所谓的DDS-RPC）。但一般来说DDS的抽象层更高。这意味着中间件为应用程序做了更多 "automatically"。具体来说。
DDS 提供自动发现
在 DDS 中，您只需 publish/subscribe 到主题名称。您永远不必提供 IP 地址、计算机名称或端口。它全部由内置发现处理。它会自动完成，无需额外服务。这意味着无需重新编译或重新配置即可重新部署和集成应用程序。
ZeroMQ 级别较低。您必须指定端口、IP 地址等。
DDS 发布-订阅以数据为中心。
一个应用程序可以发布到一个主题，但是关联的数据可以代表更新到多个数据对象，每个数据对象由键属性标识。例如，当发布飞机位置时，每次更新都可以识别 "airplane ID"，中间件可以分别为每架飞机提供历史、执行 QoS、更新率等。中间件在新飞机出现或从系统中消失时进行理解和通信。
与上述相关的DDS可以为应用程序保留相关数据的缓存，它可以根据需要查询（通过键或内容），例如读取飞机的最后 5 个位置。应用程序会收到更改通知，但不会强制立即使用它们。这也有助于减少应用程序开发人员需要编写的代码量。
DDS对"application"QoS
提供更多支持
DDS 支持超过 22 种消息和数据传递 QoS 策略，例如可靠性、端点活跃度、消息持久性和向后期加入者传递、消息过期、故障转移、定期更新监控、基于时间的过滤、排序、等等。这都是通过简单的 QoS 策略设置来配置的。该应用程序使用相同的 read/write API 并且所有额外的工作都在下面完成。
ZeroMQ 通过提供构建块和模式来解决这个问题。它非常灵活，但应用程序必须编程，assemble 并编排不同的模式以获得更高级别的行为。例如，要获得可靠的 pub-sub 需要组合多个模式，如 http://zguide.zeromq.org/page:all#toc119.
中所述
DDS 支持内容过滤、时间过滤、分区、域等附加功能...
这些在 ZeroMQ 中不可用。它们必须在应用程序层构建。
DDS提供类型系统，支持类型扩展性和可变性
您必须将 ZeroMQ 与 google protocol buffers 等其他软件包结合使用才能获得类似的功能。
安全
有一个 DDS-Security 规范提供了细粒度（主题级）的安全性，包括身份验证、加密、签名、密钥分发、安全多播等。
2。 DDS有没有比ZMQ更好的性能？
请注意，您提到的基准是针对 Object Computing Inc 的 "OpenDDS" 实施的。据我所知，这并不是最快的 DDS 实现之一。我建议您看一下其他一些，例如 RTI Connext DDS（我们的实施）、PrimsTech 的 OpenSplice DDS 或 TwinOaks 的 CoreDX DDS。当然，结果高度依赖于实际测试、网络和使用的计算机，但使用 C++ 的更快 DDS 实现的典型延迟性能约为 50 微秒，而不是 180 微秒）。参见 https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY
DDS 或 ZeroMQ 等中间件层 运行 在 UDP 或 TCP 之类的东西之上，所以我希望它们受底层网络可以做什么的约束，对于简单的情况，它们可能没有太大区别，它们当然会比原始传输差。
差异还来自他们提供的服务。因此，您应该比较相同级别的服务可以获得什么，例如可靠地发布以扩展到许多消费者、确定信息的优先级、通过 UDP 发送多个流和大数据（以避免 TCP 的队头阻塞）等。
根据您引用的 OpenDDS 研究，以及不同 DDS 实现的相对性能 (http://www.dre.vanderbilt.edu/DDS/)，我希望在同类测试中，性能更好的 DDS 实现将匹配或超过 ZeroMQ 的。
也就是说人们很少 select 为他们提供 "best performance" 的中间件。否则没有人会使用 Web 服务或 HTTP。 selection 基于多种因素，性能只需要满足应用程序的需求即可。健壮性、可扩展性、支持、风险、可维护性、编程模型对域的适用性、总拥有成本等通常对决策更重要。
3。使用 DDS（而不是 ZMQ）有明确的目的吗？
嗯，是的......在许多应用程序中，它在性能、可扩展性、功能、应用程序简单性、稳健性、风险降低和总拥有成本方面提供了最佳权衡。在过去的几年里，成千上万的项目得出了这个结论:)
杰拉尔多
我阅读了以下内容：
- DDS vs AMQP vs ZeroMQ
- http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html
而且使用 DDS 代替 zmq 似乎没有任何好处:
- zmq 的延迟更好。
- 在我看来ZMQ的API清晰简单
- 我不能使用 ZMQ 在线程/进程/站之间传输数据。
所以：
- 什么时候用DDS比较好?
- DDS 是否有比 ZMQ 更好的性能？
- 使用 DDS（而不是 ZMQ）是否有明确的目的？
谢谢
根据我作为 DDS 的（诚然有偏见的）经验 implementor/vendor 许多应用程序发现使用 DDS 比使用中间件技术（包括 ZeroMQ）有显着的好处。事实上，我看到更多 "critical applications" 使用 DDS 比使用 ZeroMQ...
首先澄清几点：
(1) DDS和它下面使用的RTPS协议是标准的，不是具体的产品。这些标准有很多实现。据我所知，至少有 9 家不同的公司拥有实施这些标准的独立产品和代码库。谈DDS vs ZeroMQ的"performance"没有意义，只能谈具体实现的性能。我稍后会解决性能问题，但仅从这个角度来看，您的陈述 "the latency of zmq is better" 显然是错误的。当然，相反的说法也是错误的。
(2) 我在您提供的第一份参考资料中没有找到很多 objective 信息。主要观点是 DDS 似乎最适合该应用程序，而且人们担心它的使用范围有多广，AC 的答复对此进行了澄清。但这些论点似乎有点主观。根据某人对特定产品代码库的主观检查，AC 的帖子得到了否定答复。即使假设发布负面评论的人有一个有效的观点，这些评论也只适用于一个特定的 DDS implementation/product 而不是一般的 DDS。就我个人而言，我不太相信该评论，它的语气似乎过于敌对，无法仅基于陈述的事实。
(3) 关于API的clarity/simplicity。您的评论是否基于您在第二个参考资料中提供的基准示例？此代码未使用标准 DDS APIs。我不确定为什么 OCI（撰写该文章的公司）会那样做——也许他们改编了其他一些先前的代码。
查看符合 DDS 规范的 API 示例的好地方是这些：
- 现代 C++：http://blogs.rti.com/2014/08/01/create-a-p2p-distributed-application-in-under-35-lines-of-c11-code/
- 经典 C++：http://www.twinoakscomputing.com/coredx/examples/hello_cpp
在任何情况下，正如我稍后提到的，DDS 和 ZeroMQ 提供的抽象层是完全不同的，因此 APIs 不能直接比较...
回答您的具体问题。
1.什么时候用DDS比较好？
很难为如此宽泛的问题提供 short/objective 答案。我确信 ZeroMQ 是一个很好的产品，很多人都很高兴。 DDS 也是如此。
我认为最好的办法是指出一些差异，让人们决定什么对他们来说是重要的。
DDS 和 ZeroMQ 在治理、生态系统、功能甚至抽象层方面都不同。
一些重要的区别：
1.1 治理、标准与生态系统
DDS 和 RTPS 是对象管理组织 (OMG) 的开放国际标准。 ZeroMQ 是一个 "loose structure controlled by its contributors"
这意味着有开放的治理和清晰的 OMG 流程来控制规范及其演变，以及 IPR 规则。
ZeroMQ IPR 在我看来不太清楚。从他们的网页 (http://zeromq.org/docs:features) 他们声明 "ZeroMQ's libzmq core is owned by its contributors" 和 "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."
这个"loose structure"对于关心知识产权谱系、保修和赔偿等问题的用户来说可能会有更多问题
与此有关。如果我理解正确的话，只有一个核心 ZeroMQ 实现（github 中的那个），并且只有它背后的公司 (iMatix)。从那里看来，只有 4 个提交者在核心 (libzmq) 中完成大部分开发工作。如果 iMatix 被收购或决定改变其商业模式，或者主要提交者失去兴趣，用户除了自己支持代码库之外几乎没有其他办法。
当然有很多成功的projects/technologies基于代码的共同所有权。另一方面，拥有与独立产品、代码库和商业模式竞争的公司生态系统为技术的未来提供了良好的保证……这完全取决于社区和生态系统的规模以及用户的风险规避程度。
1.2 特征和抽象层
DDS和ZeroMQ都支持publish-subscribe和Request-Reply等模式（这是DDS的新增功能，即所谓的DDS-RPC）。但一般来说DDS的抽象层更高。这意味着中间件为应用程序做了更多 "automatically"。具体来说。
DDS 提供自动发现
在 DDS 中，您只需 publish/subscribe 到主题名称。您永远不必提供 IP 地址、计算机名称或端口。它全部由内置发现处理。它会自动完成，无需额外服务。这意味着无需重新编译或重新配置即可重新部署和集成应用程序。
ZeroMQ 级别较低。您必须指定端口、IP 地址等。
DDS 发布-订阅以数据为中心。
一个应用程序可以发布到一个主题，但是关联的数据可以代表更新到多个数据对象，每个数据对象由键属性标识。例如，当发布飞机位置时，每次更新都可以识别 "airplane ID"，中间件可以分别为每架飞机提供历史、执行 QoS、更新率等。中间件在新飞机出现或从系统中消失时进行理解和通信。
与上述相关的DDS可以为应用程序保留相关数据的缓存，它可以根据需要查询（通过键或内容），例如读取飞机的最后 5 个位置。应用程序会收到更改通知，但不会强制立即使用它们。这也有助于减少应用程序开发人员需要编写的代码量。
DDS对"application"QoS
提供更多支持DDS 支持超过 22 种消息和数据传递 QoS 策略，例如可靠性、端点活跃度、消息持久性和向后期加入者传递、消息过期、故障转移、定期更新监控、基于时间的过滤、排序、等等。这都是通过简单的 QoS 策略设置来配置的。该应用程序使用相同的 read/write API 并且所有额外的工作都在下面完成。
ZeroMQ 通过提供构建块和模式来解决这个问题。它非常灵活，但应用程序必须编程，assemble 并编排不同的模式以获得更高级别的行为。例如，要获得可靠的 pub-sub 需要组合多个模式，如 http://zguide.zeromq.org/page:all#toc119.
中所述DDS 支持内容过滤、时间过滤、分区、域等附加功能...
这些在 ZeroMQ 中不可用。它们必须在应用程序层构建。
DDS提供类型系统，支持类型扩展性和可变性
您必须将 ZeroMQ 与 google protocol buffers 等其他软件包结合使用才能获得类似的功能。
安全
有一个 DDS-Security 规范提供了细粒度（主题级）的安全性，包括身份验证、加密、签名、密钥分发、安全多播等。
2。 DDS有没有比ZMQ更好的性能？
请注意，您提到的基准是针对 Object Computing Inc 的 "OpenDDS" 实施的。据我所知，这并不是最快的 DDS 实现之一。我建议您看一下其他一些，例如 RTI Connext DDS（我们的实施）、PrimsTech 的 OpenSplice DDS 或 TwinOaks 的 CoreDX DDS。当然，结果高度依赖于实际测试、网络和使用的计算机，但使用 C++ 的更快 DDS 实现的典型延迟性能约为 50 微秒，而不是 180 微秒）。参见 https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY
DDS 或 ZeroMQ 等中间件层 运行 在 UDP 或 TCP 之类的东西之上，所以我希望它们受底层网络可以做什么的约束，对于简单的情况，它们可能没有太大区别，它们当然会比原始传输差。
差异还来自他们提供的服务。因此，您应该比较相同级别的服务可以获得什么，例如可靠地发布以扩展到许多消费者、确定信息的优先级、通过 UDP 发送多个流和大数据（以避免 TCP 的队头阻塞）等。
根据您引用的 OpenDDS 研究，以及不同 DDS 实现的相对性能 (http://www.dre.vanderbilt.edu/DDS/)，我希望在同类测试中，性能更好的 DDS 实现将匹配或超过 ZeroMQ 的。
也就是说人们很少 select 为他们提供 "best performance" 的中间件。否则没有人会使用 Web 服务或 HTTP。 selection 基于多种因素，性能只需要满足应用程序的需求即可。健壮性、可扩展性、支持、风险、可维护性、编程模型对域的适用性、总拥有成本等通常对决策更重要。
3。使用 DDS（而不是 ZMQ）有明确的目的吗？
嗯，是的......在许多应用程序中，它在性能、可扩展性、功能、应用程序简单性、稳健性、风险降低和总拥有成本方面提供了最佳权衡。在过去的几年里，成千上万的项目得出了这个结论:)
杰拉尔多