一、DCPS概述

1.1 基本组成

• 域（Domain）
  域是DCPS内部最基本区分单元。每个实体必须属于某一个域，并且只能在相同域中与其他实体进行相互作用。应用程序代码可以通过实体自由地与多个域进行相互作用。
• 域参与者（DomainParticipant）
  域参与者是应用程序入口点，以方便在特定域中进行交互。域参与者是写入或读取数据多个对象的工厂。
• 主题（Topic）
  主题是发布、订阅应用程序之间进行交互作用的根本手段。每个主题在域里面都有一个独特的名称以及它发布的一个具体数据类型。发布数据时，发布过程总是指定主题。订阅者通过主题请求数据。在DCPS模型中，使用者可以通过不同实例发布相同主题的数据样本。
• 数据写入者（DataWriter）
  发布应用程序通过数据写入者把数值传递给DDS。每个数据写入者必须是一个特定的主题。应用程序使用数据写入者指定类型的接口，在主题上发布例子。数据写入者负责对数据编码，并传递到发布者处准备传输。
• 发布者（Publisher）
  发布者负责获取所发布的数据，并且把它分发到域中所有相关订阅者处。采用的准确机制由服务实现决定。
• 订阅者（Subscriber）
  订阅者从发布者处接受信息，并递送到任何与它相连的、相关的数据读取者上。
• 数据读取者（DataReader）
  数据读取者从订阅者处获取数据，将主题解码到适当类型中，然后把样本递送到应用程序处。每个数据读取者必须是一个特定的主题。应用程序使用数据读取程序的特定类型接口，便于接收样本。

1.2 内置主题

DDS规范定义了许多主题，这些主题被嵌入到DDS实现中。订阅这些嵌入式主题，使应用程序开发人员能访问正在被使用的域的状态，包括哪个主题被注册，哪个DataReader、DataWriter被连接以及被断开，以及各种各样实体的QoS设置。当被订阅时，应用程序接收样本，而这些样本指示在域内部、实体中所发生的改变。下表为DDS中定义的嵌入式主题。

1.3 QoS策略

DDS规范定义了许多QoS策略，应用程序利用这些策略，指定它们对于服务质量QoS的要求。参与者指定：从服务中，需要什么行为。同时，服务也决定了如何实现这些行为。这些策略可应用到DCPS的所有实体中（比如主题、DataWriter、DataReader、发布者、订阅者、域参与者），但对于所有所有实体类型而言，不是所有的策略均有效。
通过使用请求-提供（Request-Offered，RxO）模式，可以把订阅者和发布者进行匹配。订阅者请求一组最低程度需求的策略。发布者向潜在的订阅者提供一组QoS策略。然后DDS的实现利用所提供的策略，开始尝试匹配提出的策略；如果兼容，形成关联。

1.4 Listener

DCPS层为每个实体定义了一个回调接口，便于应用程序进程可以侦听（Listeners）关于那个实体的某些状态改变或者事件。例如，当不存在可以读取的可用数据时，就会通知DataReader。

1.5 条件

条件（Condition）和等待集（WaitSet）能够为Listeners在DDS中检测感兴趣的事件提供选择。一般模式为：

• 应用程序创建一种特定的Condition对象，比如状态条件，并附加到一个WaitSet上。
• 应用程序在WaitSet上等待，直到一个或多个条件为true。
• 应用程序在相应的实体对象上进行调用，以便于提取必要信息。
• DataReader接口也具有带有读取条件参数的操作。
• 提供查询条件对象，以作为订阅内容配置文件实现的一部分。查询条件接口扩展了条件参数接口。

二、OpenDDS实现

2.1 兼容性

2.1.1 DDS兼容性

DDS规范定义了DDS实现的5点兼容性：

• 最小的配置文件。
• 内容-订阅配置文件。
• 持久性配置文件。
• 所有权配置文件。
• 对象模型配置文件。

OpenDDS符合DDS规范的整个DCPS层，而且包括带有以下注释说明的所有QoS实现：

• 只有在使用TCP，IP多点发送传输，或者RTPS_UDP传输时，才支持RELIABILITY.kind=RELIABLE。
• 由于QoS可变，所以没有实现TRANSPORT_PRIORITY。

2.1.2 DDS-RTPS兼容性

OpenDDS还没有实现的项目：

• 非默认生存性（LIVELINESS）QoS。
• 写入程序方面的内容过滤。
• 关于表示（PRESENTATION）QoS的相干集合。
• 直接地写入。
• 属性列表。
• 关于持久性（DURABLE）数据的写入信息。
• 不生成键杂凑值，但是可选择。
• wait_for_acknowledgements()函数方法。
• nackSuppressionDuration以及heartbeatSuppressionDuration。

2.2 OpenDDS架构

2.2.1 设计原理

OpenDDS实现是在OMG IDL PSM严格解释说明的基础上的。几乎所有的案例中，OMG C++语言映射被用来定义如何将DDS规范中的IDL映射到C++ API，达到方便OpenDDS使用者的目的。
与OMG IDL PSM的主要区别：本地接口被用于实体以及各种其他接口。在DDS规范中，这些被定义为不受限制的非本地接口。把它们定义为本地接口，可以提高性能、减少内存的使用，简化使用者与接口的交互，让使用者更加容易创建实现。

2.2.2 可扩展传输框架

OpenDDS使用由DDS规范定义的IDL接口，以便于初始化以及控制服务使用。通过一个OpenDDS特有的传输框架，可以实现数据传输，而此框架可以允许服务利用各种传输协议，因此可称为可插拔的传输层，使得OpenDDS的架构具有很大的灵活性。
目前，OpenDDS支持TCP/IP、UDP/IP、IP多点发送、共享内存以及RTPS_UDP等多种传输协议，如图。传输协议可以通过配置文件指定，并在发布和订阅者进程中附于各种实体。

可扩传输框架能够让应用程序开发人员自行定制传输协议，包括设定一些传输框架中的级别。当创建应用时，UDP传输协议为开发人员提供了良好的使用基础，可见目录$DDS_ROOT/dds/DCPS/transport/udp。

2.2.3 DDS发现

DDS实现必须通过一些集中式代理或者分布式策略发现彼此，而OpenDDS的一个重要特征是：通过利用DCPS信息仓库（DCPSInfoRepo）或者RTPS发现（Discovery），但在DataWriter和DataReader之间采用不同的传输协议实现数据传输。
OMG DDS规范给出发现到实现的详细过程。在DDS实现之间的互操作性方面，OMG DDS-RTPS规范提供了关于发现对等类型的要求。OpenDDS提供两个关于发现的选项：

• 信息仓库 （InfoRepo）：集中式的储存库类型，其作为一个单独的进程运行，可以允许发布者和订阅者以集中式发现彼此。
• RTPS发现：一种对等的发现类型，使用RTPS协议通知可用性和本地信息。
  其他DDS实现的互操作性必须使用对等方法，但只在OpenDDS部署中才有用。

2.2.3.1 利用DCPSInfoRepo的集中式发现

DCPSInfoRepo是OpenDDS执行的一种独立式服务，以便于实现集中式方法，他作为一个CORBA服务器进行实现。当用户请求一个关于主题的订阅时，DCPSInfoRepo就会定位主题，通知发布者目前有新的订阅者。当在非RTPS配置中使用OpenDDS时，就需要运行DCPSInfoRepo，而RTPS配置时则不需要使用DCPSInfoRepo。DCPSInfoRepo不包含在数据传播中，它的任务被限制在发现彼此的OpenDDS应用程序范围内。
应用程序使用者可利用DCPS域的非重叠性部分，灵活、自由地运行多个InfoRepo。
域操作可以在多个仓库上进行，从而形成一个分布式虚拟仓库，即仓库联盟（Repository Federation）。为了使每个仓库参与到联盟中，每个仓库都必须在启动时指定它自己的联盟标识符数值（一个32位的数字值）。

2.2.3.2 利用RTPS的对等发现

需要对等发现模式的DDS应用程序可由OpenDDS性能设定，通过使用RTPS协议可以完成这种类型的发现。这个简单的发现形式可通过DDS对DataReader和DataWriter简单配置发现，如图。

当每个参与者的进程激活DataReader和写入程序的DDS-RTPS发现机制时，利用默认的或者配置的网络端口，网络端点才能被创建，以便于DDS参与者可以发布DataReader以及写入程序的可用性。一段时间后，基于标准的、彼此寻觅的那些就会基于所配置的、可插拔的传输协议，发现彼此并建立一个连接。
当开发并部署需要使用RTPS发现的应用程序时，开发人员需考虑以下限制因素：

• 由于UDP端口的方式被分配给域ID，那么，域ID应当在0~231（包含231）之间。在每个OpenDDS进程、每个域中，支持多达120个域参与者。
• 主题名称以及类型识别码被限制到256个字符。
• 由于全局唯一标识符（GUID）的方式被指定，OpenDDS的本地多点发送传输不能与RTPS发现一并工作（如果试图这样，那么将发布一个警告信息）。

2.2.4 线程

OpenDDS创建ORB以及单独的线程。它也使用它自己的线程，以便于处理输入的和输出的非COBRA传输I/O。由于存在不能预料的连接关闭，创建一个单独的线程，以便于资源的清除。应用程序可通过DCPS的Listener机制，从这些线程中得到回调。
当通过DDS发布一个样本时，OpenDDS试图通过调用线程把样本发送给已连接的任何订阅者。如果发送线程被堵塞，那么样本可能在单独的服务线程上，排队等待着发送。此行为取决于QoS策略的设定值。
所有订阅者中的输入数据，由服务线程进行读取，并由应用程序进行排队，等待读取。从服务线程调用DataReaderListener。

2.2.5 配置

OpenDDS包括一个基于文件的配置框架，用于配置全局项。例如调试级别、内层分配以及发现，以及关于发布者和订阅者的传输实现详细信息。也可以直接以代码的方式实现配置，但建议使配置具体化，以便于是维护变得简单，并且减少运行时的错误。