DDS 中的互操作性

Posted 2023-02-16

【中文标题】DDS 中的互操作性

【英文标题】：Interoperability in DDS

【发布时间】：2016-01-20 08:36:30

【问题描述】：

我是 DDS 域的新手，需要有以下理解。

如何发布两个供应商之间的共同话题以实现 ？

场景是： 假设有两个供应商产品 V1 和 V2。 V1 有一个发布者在主题 T1 上发布。 V2想订阅这个topic。Subscriber(V2)怎么知道有一个Topic T1？

我对域级别也有类似的疑问。订阅者如何知道它必须参与哪个域？

我正在使用 OpenDDS。

谢谢

【参考方案1】：

供应商之间的互操作性是可能的，并由主要供应商定期测试/演示。

您需要配置您的 DDS 实现以使用 RTPS（我认为目前是 RTPS2），而不是供应商可能使用的任何专有传输。这可能默认启用。

就要参与的域而言，您以编程方式在特定域中创建域参与者（它连接到的域可能由配置文件控制）以及您创建的所有其他实体（发布者、订阅者等）然后属于该域参与者，因此在该域中运行

【参考方案2】：

要在@rcs 的答案基础上再做一点……您必须做的实际工作量可能取决于 DDS 实现（OpenDDS、RTI、Prismtech...），因为它们将具有不同的默认值。如果您在两端使用相同的配置，那么您的配置会变得更加简单，因为默认值应该与域和 RTPS 等内容一致。

您需要确保以下匹配：

域 ID 域分区 传输（我推荐 RTPS，根据我的经验，2.1 和 2.2 之间的 FWIW 版本差异并不重要） TCP 或 UDP 发现端口和数据端口 - 这将或多或少取决于您使用的实现以及您是否在连接的两端使用相同的端口，如果使用相同，它们将具有相同的默认值。 确保一个发布的主题与另一个订阅的主题匹配，这将适用于主题和类型 (see more here) 数据序列化 发现（单播与多播，确保 您选择的任何设置都是有效的，例如：两个设备都在同一个 组播组） QoS 设置需要对齐，但我认为默认设置可能会起作用 (read more here) 首先让 Shapes 演示在您正在使用的机器之间运行，这会进行一些基本的健全性检查，以了解在给定的配置和网络设置下是否可行。我见过的每个供应商/实现都有一个要运行的形状演示，例如，here is RTI's。

目前能想到的就这么多，希望对你有帮助。我发现 DDS 文档非常好，特别是如果您知道何时可以（以及何时不能）使用任何供应商文档的答案来实现您的实施（例如：在 RTI 的文档或论坛上找到的答案以及它是否适用于您的 OpenDDS 应用程序）。通常解决方案是相似的，但您会发现 RTI 支持最多，并且 RTI + Prismtech 拥有一些最好的文档。

【参考方案3】：

DDS RTPS 协议交换发现信息，以便参与同一域 (!) 的不同应用程序知道谁在外面，以及他们提供/请求什么。您需要确保两个应用程序使用相同的域 ID（在域参与者上指定）。此外，由于某些实现允许不同的传输选项，请确保使用 RTPS（有时称为 DDSI）网络。

RTPS 规范包含从域 ID 到端口号的映射，因此如果来自不同供应商的应用程序使用相同的 ID，它应该可以正常工作。但是，实现可能会使用配置覆盖端口号。

为了最大限度地提高应用程序正确通信的机会，请确保它们使用相同的 IDL 数据模型。供应商有不同的方法来处理不完全匹配的类型演变/映射类型，而且并非所有供应商都实现了 XTypes 规范（目前）。

此外，由于某些实现比其他实现更严格，请确保您保持在规范的范围内。这意味着主题名称只能包含字母数字字符（我有时会看到 ':' 表示范围，这是不允许的）。

供应商之间绝对行不通的事情是 TRANSIENT/PERSISTENT 持久性或基于 TCP 的通信，因为两者都还没有标准化。 TRANSIENT_LOCAL 应该可以工作。 TRANSIENT_LOCAL 和 TRANSIENT 的区别在于，使用 TRANSIENT_LOCAL，发布者（作者）离开系统后数据不再对齐，而使用 TRANSIENT，数据仍然可用。

另外请注意，对于供应商之间的 API 级互操作性，最好的机会是使用新的 isocpp API，因为在我见过的供应商实施中，该 API 的实施非常一致。

希望有帮助！