OpenDDS开发手册---第一章3

1.2 OpenDDS实现

1.2.1 法规遵从性

    OpenDDS 符合 omg dds 和 omg DDSI-RTPS 规范。遵守的细节情况如下。

1.2.1.1 dds 合规性

    dds 规范的第2节为 dds 实现定义了五个合规点:

1. 最小配置文件           Minimum Profile
   
2. 内容-订阅配置文件  Content-Subscription Profile
   
3. 持久性配置文件        Persistence Profile
   
4. 所有权配置文件        Ownership Profile
   
5. 对象模型配置文件    Object Model Profile 

    OpenDDS 符合整个 dds 规范 (包括所有可选配置文件)。这
包括执行所有质量服务策略, 并提供以下说明:

• RELIABILITY.kind = RELIABLE 当 tcp 或 ip 多址广播传输时才支持可靠
  (配置为可靠) 或使用 RTPS_UDP 传输时
  
• TRANSPORT_PRIORITY 未实现为可变
  

1.2.1.2  DDSI-RTPS Compliance

     OpenDDS 执行符合 omg DDSI-rtps 的要求规范.

OpenDDS RTPS 实现说明：

omg DDSI-RTPS 规范 (formal/2014-09-01) 提供声明实现, 但不要求法规遵从性。下列项目应纳入考虑，当使用 OpenDDS RTPS 功能的传输和/或发现。DDSI-RTPS 规范的节号为每个项目提供进一步的参考。
    未在 opendds 中实现的项目：

1. 编写器端内容筛选 (8.7.3)  ，OpenDDS 可能仍会丢弃不需要的示例 (由于内容筛选)关联的读取器-这是在传输层之上完成的。
   
2. PRESENTATION qos 的相干集 (8.7.5)
   
3. 定向写入 (8.7.6)
   
4. 属性列表 (8.7.7)
   
5. 原始的写者信息为 DURABLE的数据 (8.7.8)-这只将用于瞬变和持久耐用性（transient and persistent durability
   ）, 不受 RTPS 规范的支持 (8.7. 2.2. 1)
   
6. 不生成密钥哈希 (8.7.9), 但它们是可选的
   
7. nackSuppressionDuration (Table 8.47) and heartbeatSuppressionDuration(Table 8.62)
   

注意：DDSI-RTPS 规范中描述了上面的项目3和4。然而, 它们在 dds 规范中没有相应的概念。

1.2.2    dds 规范的扩展

    dds idl 模块中的数据类型、接口和常量 (c++ 命名空间, java包) 与 dds 规范直接对应, 但有很少的几个例外:

•  DDS::SampleInfo 包含一个以 "opendds_reserved" 开头的额外字段
  
• 类型特定的 DataReaders (包括内置主题的) 有额外的operatons read_instance_w_condition () 和 take_instance_w_condition ()。

     其他扩展行为由 opendds 中的各种类和接口在OpenDDS的模块/命名空间/包。这些功能包括Recorder and Replayer (见12章) 和:

• OpenDDS::DCPS::TypeSupport 添加 unregister_type () 中，不在dds 规范。
  
• OpenDDS::DCPS::ALL_STATUS_MASK, NO_STATUS_MASK, and DEFAULT_STATUS_MASK 是用于 dds 的常用DDS::StatusMask 类型，通过 DDS::Entity, DDS::StatusCondition,和各种 create_ * () 操作 。
  

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 的 c++ 语言映射用于 corba idl定义了 dds 规范中的 idl 如何映射到  c++ api ，opendds中向客户端公开的接口。
    从 OMG IDL PSM 的主要偏差是, 本地接口用于实体和各种其他接口。这些被定义为无约束 (非本地) 接口在dds 规范中。将它们定义为本地接口可提高性能, 减少内存使用, 简化了客户端与这些接口的交互, 并使它更容易为客户构建自己的实现。

1.2.3.2   可扩展运输框架 (ETF)

    OpenDDS 使用 dds 规范定义的 idl 接口来初始化和控制服务使用。数据传输是通过 OpenDDS 特定的传输完成的
允许服务与各种传输协议一起使用的框架。这是称为可插拔传输, 并使 OpenDDS 的可扩展性成为重要其体系结构的一部分。OpenDDS 当前支持 tcp/ip、udp/ip、ip 多播、共享内存 和 RTPS_UDP 传输协议, 如图1-2 所示。传输是
通常通过配置文件指定, 并附加到发布服务器和订阅服务器进程。有关etf 组件的详细信息, 请参阅7.4.4 节。

    ETF 使应用程序开发人员能够实现自己的自定义传输。实现自定义传输涉及专门在运输框架。udp 传输提供了良好的基础开发人员可以使用创建自己的实现时。详细信息见$DDS_ROOT/dds/DCPS/transport/udp/ 的目录。

1.2.3.3 DDS Discovery发现

    dds 应用程序必须通过一些中央代理或通过一些分布式方案。OpenDDS 的一个重要特点是 dds 应用程序可以
配置为使用 DCPSInfoRepo 或 RTPS 发现执行发现, 但利用数据编写者和数据读取器之间数据传输的不同传输类型。omg dds 规范 (formal/2015-04-10) 将发现的细节留给实现.在 dds 实现之间的互操作性的情况下, omg DDSI-RTPS (正式/2014-09-01) 规范为对等的发现方式。

OpenDDS 提供了两个用于发现的选项。

1. 信息存储库: 作为单独进程运行的集中式存储库样式允许发布者与订阅者在中央或中心之间发现彼此。
   
2. RTPS 发现: 一种利用 RTPS 协议的对等的发现方式公布可用性和位置信息。
   

    与其他 dds 实现的互操作性必须使用对等方法, 但在仅 OpenDDS 的部署中可以很有用。

dcpsinforepo 的集中式发现

    OpenDDS 实现一个称为 "DCPS 信息存储库（DCPS Information Repository ）" 的独立服务(DCPSInfoRepo) 实现集中的发现方法。它是作为一个 corba 实现的服务器.当客户端请求订阅某个主题时, DCPS Information Repository
查找主题并通知任何现有的发布者新订阅服务器的位置。在 non-RTPS 配置中使用 OpenDDS 时, 需要运行 DCPSInfoRepo 进程。RTPS 配置不使用 DCPSInfoRepo。DCPSInfoRepo 不参与数据传播, 其作用范围限于 opendds应用程序互相发现。

   应用程序开发人员可以自由运行多个信息存储库, 每个管理它们自己的不重叠的 DSPS域集。还可以使用多个存储库来操作域, 从而形成分布式虚拟存储库。这称为存储库联盟。为了单独的存储库参与联盟, 每一个都必须指定自己的
启动时的联合标识符值 (32 位数值)。见9.2 进一步有关存储库联盟的信息

RTPS 的对等发现

   需要对等发现模式的 dds 应用程序可以由OpenDDS 能力。这种发现的方式只有通过使用当前版本的 RTPS 协议。这种简单的发现形式是通过简单的配置 dds 应用程序数据读取者和数据写入者程序来实现的。如错误所示的应用程序进程: 找不到引用源。每个参与进程激活 OpenDDS 中的 DDSI RTPS 发现机制, 用于数据读取者和写入者, 网络端点是使用默认或配置的网络端口创建的这样, dds 参与者就可以开始公布其数据读取者和数据写入者的可用性。经过一段时间, 那些寻求一个基于标准的人会发现彼此建立一个基于配置的可插拔传输的连接, 作为在可扩展传输框架 (etf) 中讨论。更详细的描述7.4.1.1 节和7.4.5.5 节讨论了灵活的配置方法。
    以下是开发人员需要考虑的附加实施限制，在开发和部署使用 RTPS 发现的应用程序时考虑:

1. 由于 udp 端口的方式, 域 id 应介于0和 231 (包含) 之间分配给域 id。在每个 OpenDDS 过程中, 多达120域参与者在每个域中都受支持。
   
2. 主题名称和类型标识符限制为256个字符
   
3. OpenDDS 的本地多址广播传输不能与 RTPS 发现一起使用, 原因是分配 guid 的方式 (如果尝试此方法, 将发出警告)。
   

     有关如何 RTPS 发现的详细信息, 可以找到一个非常好的阅读参考在8.5 节中, 实时发布-订阅线协议 dds 互操作线
协议规范 (DDSI-RTPS) v2.2 (omg 文档 formal/2014-09-01)

1.2.3.4 线程

    OpenDDS 创建自己的 orb (当一个是必需的) 以及一个单独的线程后运行该ORB。它还使用自己的线程来处理传入和传出传输 i/o。创建一个单独的线程以在意外时清除资源连接关闭。您的应用程序可能会被从这些线程调用回DCPS 的监听机制。通过 dds 发布示例时, OpenDDS 通常尝试将示例发送到任何使用调用线程连接的订阅服务器。如果发送调用阻止, 则示例可能在单独的服务线程上排队等待发送。此行为取决于 qos 在第3章所述的政策。
   订阅服务器中的所有传入数据都由一个服务线程读取, 并排队等待应用程序。从服务线程调用 datareader 侦听器。

1.2.3.5 配置

    OpenDDS 包括用于配置两个全局项的基于文件的配置框架如调试级别、内存分配和发现以及传输实现发布者和订户的详细信息。也可以直接在代码中实现配置,但是, 建议将配置具体化以便于维护和减少运行时错误。完整的配置选项集描述在第7章。