OPENDDS_开发者文档系列_2

目录

1.2 OpenDDS实现

1.2.1 合规性

1.2.2 DDS规范的扩展

1.2.3 OpenDDS架构

---

 

1.2 OpenDDS实现

1.2.1 合规性

    OpenDDS符合OMG DDS和OMG DDSI-RTPS规范。 这种合规的细节如下。

1.2.1.1 DDS合规性DDS规范的第2部分定义了DDS实施的五个合规点：

           1）最低档案

           2）内容订阅配置文件

           3）持久性配置文件

           4）所有权简介

           5）对象模型简介

OpenDDS符合整个DDS规范（包括所有可选配置文件）。 这包括使用以下注释实施所有服务质量政策：

           •   仅当使用TCP或IP多播传输（配置为可靠）或使用RTPS_UDP传输时，才支持RELIABILITY.kind = RELIABLE。

           •   TRANSPORT_PRIORITY未实现为可更改。

1.2.1.2 DDSI-RTPS 合规性

OpenDDS实现符合OMG DDSI-RTPS规范的要求。

OpenDDS RTPS实施说明

      1）编写者内容过滤-OpenDDS仍然可以丢弃任何相关读者不需要的样本（由于内容过滤） - 这是在传输层上面完成的

      2）演示QoS的相干集

      3）定向写

      4）财产清单

      5）DURABLE数据的原始编写器信息 - 这仅用于瞬态和持久耐久性，RTPS规范不支持这些

      6）不生成密钥哈希，但它们是可选的

      7）nackSuppressionDuration和heartbeatSuppressionDuration。

注意：上述第3和第4项在DDSI-RTPS规范中有所描述。 但是，它们在DDS规范中没有相应的概念。

1.2.2 DDS规范的扩展

DDS IDL模块（C ++命名空间，Java包）中的数据类型，接口和常量直接对应于DDS规范，只有极少数例外：

  •   DDS :: SampleInfo包含以“opendds_reserved”开头的额外字段

  •   特定于类型的DataReader（包括内置主题的DataReader）具有其他操作read_instance_w_condition（）和take_instance_w_condition（）。

OpenDDS模块/命名空间/包中的各种类和接口提供了额外的扩展行为。 其中包括Recorder和Replayer等功能以及：

  •    OpenDDS :: DCPS :: TypeSupport添加了DDS规范中未找到的unregister_type（）操作。

  •    OpenDDS :: DCPS :: ALL_STATUS_MASK，NO_STATUS_MASK和DEFAULT_STATUS_MASK是DDS :: Entity，DDS :: StatusCondition和各种create _ *（）操作使用的DDS :: StatusMask类型的有用常量。

1.2.3 OpenDDS架构

本节简要概述了OpenDDS实现，其功能及其一些组件。 $ DDS_ROOT环境变量应指向OpenDDS分发的基本目录。 OpenDDS的源代码可以在$ DDS_ROOT / dds /目录下找到。 DDS测试可以在$ DDS_ROOT / tests /下找到。

1.2.3.1 设计理念

       OpenDDS实现和API基于对OMG IDL PSM的相当严格的解释。 在几乎所有情况下，OMG的CORBA IDL C ++语言映射用于定义DDS规范中的IDL如何映射到OpenDDS向客户端公开的C ++ API中。与OMG IDL PSM的主要偏差是本地接口用于实体和各种其他接口。 这些被定义为DDS规范中的无约束（非本地）接口。 将它们定义为本地接口可以提高性能，减少内存使用，简化客户端与这些接口的交互，并使客户端更容易构建自己的实现。

1.2.3.2 可扩展传输框架（ETF）

       OpenDDS使用DDS规范定义的IDL接口来初始化和控制服务使用。 数据传输是通过OpenDDS特定的传输框架完成的，该框架允许服务与各种传输协议一起使用。 这被称为可插拔传输，并使OpenDDS的可扩展性成为其体系结构的重要组成部分。 OpenDDS目前支持TCP / IP，UDP / IP，IP多播，sharedmemory和RTPS_UDP传输协议，如图所示。 传输通常通过配置文件指定，并附加到发布者和订阅者进程中的各种实体。

        ETF使应用程序开发人员能够实现自己的定制传输。实现自定义传输涉及专门化传输框架中定义的许多类。 udp传输为开发人员在创建自己的实现时可能使用提供了良好的基础。 有关详细信息，请参阅$ DDS_ROOT / dds / DCPS / transport / udp /目录。

1.2.3.3 使用DCPSInfoRepo进行集中发现

       DDS应用程序必须通过某个中央代理或通过某种分布式方案相互发现。 OpenDDS的一个重要特性是可以将DDS应用程序配置为使用DCPSInfoRepo或RTPS发现执行发现，但使用不同的传输类型在数据写入器和数据读取器之间进行数据传输。

OpenDDS提供了两种发现选项。

1）信息库：一种集中的存储库样式，作为一个单独的过程运行，允许发布者和订阅者集中或相互发现

2）RTPS发现：一种对等的发现方式，利用RTPS协议来通告可用性和位置信息。 与其他DDS实现的互操作性必须使用对等方法，但在仅限OpenDDS的部署中非常有用。

使用DCPSInfoRepo进行集中发现

        OpenDDS实现了一个名为DCPS信息存储库（DCPSInfoRepo）的独立服务，以实现集中式发现方法。 它作为CORBA服务器实现。 当客户端请求订阅主题时，DCPS信息存储库定位主题并通知任何现有发布者新订户的位置。只要在非RTPS配置中使用OpenDDS，就需要运行DCPSInfoRepo进程。 RTPS配置不使用DCPSInfoRepo。 DCPSInfoRepo不参与数据传播，其作用范围仅限于OpenDDS应用程序相互发现应用程序开发人员可以自由运行多个信息库，每个信息库都管理自己的非重叠DCPS域集。还可以操作具有多个存储库的域，从而形成分布式虚拟存储库。 这称为存储库联合。 为了使单个存储库参与联合，每个存储库在启动时必须指定其自己的联合标识符值（32位数值）。

使用RTPS进行点对点发现

       OpenDDS功能可以满足需要点对点发现模式的DDS应用。这种发现方式仅通过使用当前版本的RTPS协议来完成。这种简单的发现形式是通过简单配置DDS应用程序数据读取器和在应用程序进程中运行的数据编写器来完成的，如错误：未找到参考源中所示。由于每个参与过程都在OpenDDS中为其数据读取器和写入器激活DDSI-RTPS发现机制，因此可以使用默认或配置的网络端口创建网络端点，以便DDS参与者可以开始宣传其数据读取器和数据写入器的可用性。在一段时间之后，基于标准寻求彼此的人将找到彼此并基于配置的可插拔传输建立连接，如可扩展传输框架（ETF）中所讨论的。以下是开发人员在开发和部署使用RTPS发现的应用程序时需要考虑的其他实施限制：

1）由于UDP端口分配给域ID的方式，域ID应介于0和231之间（包括0和231）。 在每个OpenDDS流程中，每个域中最多支持120个域参与者。

2）主题名称和类型标识符限制为256个字符。

3）由于GUID的分配方式，OpenDDS的本地多播传输不能与RTPS Discovery一起使用（如果尝试这样做，将发出警告）。

 

1.2.3.4 多线程

        OpenDDS创建自己的ORB（当需要一个ORB时）以及运行该ORB的单独线程。 它还使用自己的线程来处理传入和传出的传输I / O. 创建单独的线程以在意外连接关闭时清理资源。 您的应用程序可能会通过DCPS的侦听器机制从这些线程回调。通过DDS发布样本时，OpenDDS通常会尝试使用调用线程将样本发送给任何连接的订户。 如果发送调用阻塞，则样本可以排队等待在单独的服务线程上发送，这种行为依赖于QOS策略。订户中的所有传入数据都由服务线程读取，并排队等待应用程序读取。 从服务线程调用DataReader侦听器。

1.2.3.5 配置

        OpenDDS包括一个基于文件的配置框架，用于配置调试级别，内存分配和发现等全局项，以及发布者和订阅者的传输实现详细信息。 配置也可以直接在代码中实现，但是，建议将配置外部化以便于维护和减少运行时错误。