【OpenDDS开发指南V3.20】第一章：介绍

OpenDDS 是用于实时系统规范 v1.4（OMG Document formal/2015-04-10）的 OMG 数据分发服务 (DDS) 和实时发布订阅有线协议DDS Interoperability Wire Protocol Specificatio (DDSI- RTPS）v2.3（OMG Document formal/2019-04-03）。

OpenDDS 还实现了 DDS 安全规范 v1.1（OMG Document formal/2018-04-01）和 DDS XTypes v1.3（OMG Document formal/2020-02-04）。

OpenDDS 由 Object Computing, Inc. (OCI) 赞助，可在 https://www.opendds.org/ 获得。本开发人员指南基于 OpenDDS 的 3.20 版本。

DDS 定义了一种服务，用于在分布式应用程序的参与者之间有效地分发应用程序数据。此服务不绑定到 CORBA。该规范提供了一个平台独立模型 (PIM) 以及一个将 PIM 映射到 OMG IDL 实现的平台特定模型 (PSM)。

有关 DDS 的更多详细信息，开发人员应参考 DDS 规范（OMG Document formal/2015-04-10），因为它包含对所有服务功能的深入介绍。

注意:OpenDDS 当前实现了 OMG DDS 1.4 版规范。有关更多信息，请参阅 https://www.opendds.org/ 中的合规信息。

DCPS 概述

在本节中，我们将介绍 DCPS 层的主要概念和实体，并讨论它们如何交互和协同工作。

基本概念

图 1-1 显示了 DDS DCPS 层的概览。以下小节定义了此图中显示的概念。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VcUUwFh1-1652410199857)(https://note.youdao.com/yws/res/2874/WEBRESOURCE8b0550fd5df1608881ecff7b6d1cbb7d)]

Domain(域)

Domain是 DCPS 中的基本划分单元。

每个其他实体都属于一个Domain，并且只能与同一Domain中的其他实体交互。

应用程序代码可以自由地与多个Domain交互，但必须通过属于不同Domain的单独实体来进行。

DomainParticipant(域参与者)

域参与者是应用程序在特定域中交互的入口点。

域参与者是许多涉及写入或读取数据的对象的工厂。

Topic

主题是发布和订阅应用程序之间交互的基本方式。

每个主题在域中都有一个唯一的名称和它发布的特定数据类型。

每个主题数据类型都可以指定零个或多个构成其键的字段。发布数据时，发布过程始终指定主题。订阅者通过主题请求数据。

在 DCPS 术语中，您针对某个主题的不同实例发布单独的数据样本。每个实例都与键的唯一值相关联。发布过程通过对每个样本使用相同的键值，在同一实例上发布多个数据样本。

DataWriter

发布应用程序代码使用数据写入器将值传递给 DDS。每个数据编写器都绑定到一个特定的主题。

应用程序使用数据编写器的类型特定接口发布关于该主题的示例。数据写入者负责编组数据并将其传递给发布者进行传输。

Publisher(发布者)

发布者负责获取发布的数据并将其传播给域中的所有相关订阅者。所采用的确切机制留给服务实现。

Subscriber(订阅者)

订阅者从发布者接收数据并将其传递给与其连接的任何相关数据读取器。

DataReader(数据读取器)

数据读取器从订阅者那里获取数据，将其分解为适合该主题的类型，然后将样本交付给应用程序。每个数据阅读器都绑定到一个特定的主题。应用程序使用数据读取器的特定类型接口来接收样本。

Built-In Topics(内置主题)

DDS 规范定义了许多内置于 DDS 实现的主题。

订阅这些内置主题使应用程序开发人员可以访问正在使用的域的状态，包括注册了哪些主题、连接和断开了哪些数据读取器和数据写入器，以及各种实体的 QoS 设置。

订阅时，应用程序会收到指示域内实体更改的样本。下表显示了 DDS 规范中定义的内置主题：

Topic Name	Description
DCPSParticipant	每个实例代表一个域参与者
DCPSTopic	每个实例代表一个普通（非内置）主题
DCPSPublication	每个实例代表一个数据写入器
DCPSSubscription	每个实例代表一个数据读取器

服务质量政策

DDS 规范定义了许多服务质量 (QoS) 策略，应用程序使用这些策略来指定其对服务的 QoS 要求。

参与者指定他们需要从服务中获得什么行为，而服务决定如何实现这些行为。

这些策略可以应用于各种 DCPS实体（主题、数据写入器、数据读取器、发布者、订阅者、域参与者），尽管并非所有策略都对所有类型的实体都有效。

订阅者和发布者使用请求与提供 (RxO) 模型进行匹配。

订阅者请求一组最低要求的策略。发布者向潜在订阅者提供一组 QoS 策略。然后，DDS 实现尝试将请求的策略与提供的策略匹配；如果这些策略是兼容的，那么就形成了关联。

OpenDDS 目前实施的策略将在第 3 章详细讨论。

监听

DCPS 层为每个实体定义了一个回调接口，允许应用程序进程“监听”与该实体相关的某些状态更改或事件。例如，当有数据值可供读取时，会通知数据读取器侦听器。

条件

条件和等待集允许在 DDS 中检测感兴趣的事件时替代侦听器。

一般模式是应用程序创建特定类型的 Condition 对象，例如 StatusCondition，并将其附加到 WaitSet。

应用程序在 WaitSet 上等待，直到一个或多个条件变为真。
应用程序调用对相应实体对象的操作以提取必要的信息。
DataReader 接口还具有采用ReadCondition 参数的操作。
QueryCondition 对象作为 ContentSubscription Profile 实现的一部分提供。 QueryCondition 接口扩展了 ReadCondition 接口。

penDDS 实施

规范

OpenDDS 符合 OMG DDS 和 OMG DDSI-RTPS 规范。
该合规性的详细信息如下。 OpenDDS 还实现了 OMG DDS 安全规范。符合该规范的详细信息在第 14.8 节中。

XTypes 合规性的详细信息在第 16.8 和 16.9 节中。

DDS 规范

DDS 规范的第 2 节定义了 DDS 实施的五个合规点：

最低配置文件
内容订阅配置文件
持久性配置文件
所有权概况
对象模型配置文件

OpenDDS 符合整个 DDS 规范（包括所有可选配置文件）。这包括实施所有服务质量政策，并附有以下说明：

RELIABILITY.kind = RELIABLE 受RTPS_UDP 传输、TCP 传输或IP 多播传输（配置为可靠时）支持。
TRANSPORT_PRIORITY 未实现为可更改的。尽管 DDS 规范的 1.5 版尚未发布，但 OpenDDS 包含了为该版本计划的一些更改，这些更改是稳健实施所需的：
- DDS15-257：IDL 类型 BuiltinTopicKey_t 是一个包含
  16 个八位字节的数组

DDSI-RTPS 规范

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

OpenDDS RTPS 实施说明

OMG DDSI-RTPS 规范（formal/2019-04-03）提供了实施声明，但并非合规性要求。在使用 OpenDDS RTPS 功能进行传输和/或发现时，应考虑以下事项。

DDSI-RTPS 规范的章节编号随每个项目一起提供，以供进一步参考。
OpenDDS 中未实现的项目：

Writer端内容过滤（8.7.3）
OpenDDS 可能仍然会丢弃任何相关阅读器不需要的样本（由于内容过滤）——这是在传输层之上完成的
PRESENTATION QoS (8.7.5) 的相干集
定向写入 (8.7.6)
– OpenDDS 将使用 Directed Write 参数，如果它出现在传入消息中（例如，由不同 DDS 实现生成的消息）
属性列表 (8.7.7)
DURABLE 数据 (8.7.8) 的原始写入者信息——这将仅用于 RTPS 规范 (8.7.2.2.1) 不支持的瞬态和持久性持久性
Key Hashes (8.7.9) 不会生成，但它们是可选的
nackSuppressionDuration（表8.47）和heartbeatSuppressionDuration（表8.62）。

IDL 规范

OMG IDL 在 OpenDDS 代码库和下游以几种不同的方式使用
使用它的地方：

OpenDDS 附带的文件（例如 dds/DdsDcpsTopic.idl）定义了中间件库和应用程序之间的 API 部分。这称为 OMG IDL 平台特定模型 (PSM)。
除了 C++ 或 Java 的源代码文件之外，OpenDDS 的用户还可以编写 IDL 文件。

本节只描述后者的使用。

IDL 规范（4.2 版）使用术语“构建块”来定义某些工具可能支持的整个 IDL 语法的子集。

OpenDDS 支持以下构建块，下面列出了注释/警告：

核心数据类型
- 对“固定”数据类型（定点小数）的支持不完整。
匿名类型
- 当匿名类型作为序列/数组实例直接作为结构字段类型出现时，对匿名类型的支持有限。建议使用显式命名的类型。
注释
- 有关支持的内置注释的详细信息，请参阅第 2.1.1 和 16.6 节。
- 还支持用户定义的注释类型。
扩展数据类型
整数类型 int8、int16、int32 和 int64 以及无符号版本
支持它们，例如 uint32。
不支持构建块的其余部分。

DDS 规范的扩展

DDS IDL 模块（C++ 命名空间、Java 包）中的数据类型、接口和常量直接对应于 DDS 规范，只有极少数例外：
• DDS::SampleInfo 包含一个以“opendds_reserved”开头的额外字段
• 特定类型的DataReader（包括那些用于内置主题的）具有额外的操作read_instance_w_condition() 和take_instance_w_condition()。

OpenDDS 模块/命名空间/包中的各种类和接口提供了额外的扩展行为。其中包括 Recorder 和 Replayer 等功能（参见第 12 章）以及：
• OpenDDS::DCPS::TypeSupport 添加了 DDS 规范中没有的 unregister_type() 操作。
• OpenDDS::DCPS::ALL_STATUS_MASK、NO_STATUS_MASK 和 DEFAULT_STATUS_MASK 是 DDS::Entity、DDS::StatusCondition 和各种 create_*() 操作使用的 DDS::StatusMask 类型的有用常量。

OpenDDS 架构

本节简要概述了 OpenDDS 的实现、它的特性以及它的一些组件。 $DDS_ROOT 环境变量应该指向 OpenDDS 发行版的基本目录。 OpenDDS 的源代码可以在 $DDS_ROOT/dds/ 目录下找到。 DDS 测试可以在 $DDS_ROOT/tests/ 下找到。

设计理念

OpenDDS 实现和 API 基于对 OMG IDL PSM 的相当严格的解释。

在几乎所有情况下，OMG 的 IDL-to-C++ 语言映射都用于定义 DDS 规范中的 IDL 如何映射到 OpenDDS 向客户端公开的 C++ API。

与 OMG IDL PSM 的主要偏差是本地接口用于实体和各种其他接口。这些在 DDS 规范中被定义为不受约束的（非本地）接口。将它们定义为本地接口可以提高性能，减少内存使用，简化客户端与这些接口的交互，并使客户端更容易构建自己的实现.

可扩展传输框架 (ETF)

OpenDDS 使用 DDS 规范定义的 IDL 接口来初始化和控制服务的使用。

数据传输是通过特定于 OpenDDS 的传输框架完成的，该框架允许服务与各种传输协议一起使用。

这被称为可插拔传输，并使 OpenDDS 的可扩展性成为其架构的重要组成部分。 OpenDDS 目前支持 TCP/IP、UDP/IP、IP 多播、共享内存和 RTPS_UDP 传输协议，如图 1-2 所示。

传输通常通过配置文件指定，并附加到发布者和订阅者进程中的各种实体。有关配置 ETF 组件的详细信息，请参阅第 7.4.4 节

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iJVPmlo9-1652410199858)(https://note.youdao.com/yws/res/2971/WEBRESOURCE0f1e9d5a37f72b244d07554ab3b0cd27)]

ETF 使应用程序开发人员能够实现他们自己的定制传输。实现自定义传输涉及专门化传输框架中定义的许多类。

udp 传输提供了开发人员在创建自己的实现时可以使用的良好基础。有关详细信息，请参阅 $DDS_ROOT/dds/DCPS/transport/udp/ 目录。

DDS Discovery

DDS 应用程序必须通过某个中央代理或某个分布式方案来发现彼此。

OpenDDS 的一个重要特性是 DDS 应用程序可以配置为使用 DCPSInfoRepo 或 RTPS 发现来执行发现，但在数据写入器和数据读取器之间使用不同的传输类型进行数据传输。

DDS 规范（正式/2015-04-10）将发现的细节留给实现。

在 DDS 实现之间的互操作性的情况下，OMG DDSI-RTPS（正式/2014-09-01）规范提供了对等发现风格的要求。

OpenDDS 提供了两个发现选项：

信息存储库：一种集中式存储库样式，作为一个单独的进程运行，允许发布者和订阅者集中发现彼此或
RTPS 发现：一种点对点的发现方式，它利用 RTPS 协议来宣传可用性和位置信息。与其他 DDS 实现的互操作性必须利用对等方法，但在仅 OpenDDS 的部署中可能很有用。

DCPSInfoRepo 的集中式发现

OpenDDS 实现了一个名为 DCPS 信息存储库 (DCPSInfoRepo) 的独立服务来实现集中式发现方法。

它被实现为 CORBA 服务器。

当客户请求订阅某个主题时，DCPS 信息库会定位该主题并通知任何现有发布者新订阅者的位置。每当在非 RTPS 配置中使用 OpenDDS 时，都需要运行 DCPSInfoRepo 进程。

RTPS 配置不使用 DCPSInfoRepo。 DCPSInfoRepo 不参与数据传播，其作用仅限于发现彼此的 OpenDDS 应用程序。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b68Jxii6-1652410199858)(https://note.youdao.com/yws/res/2983/WEBRESOURCEb3ef55e501340bf47c2752d76a29db3f)]

应用程序开发人员可以自由运行多个信息存储库，每个存储库管理自己的非重叠 DCPS 域集。

还可以使用多个存储库来操作域，从而形成分布式虚拟存储库。这称为存储库联合。为了让各个存储库参与联合，每个存储库都必须在启动时指定自己的联合标识符值（32 位数值）。有关存储库联合的更多信息，请参见 9.2。

使用 RTPS 的点对点发现

OpenDDS 功能可以满足需要对等发现模式的 DDS 应用程序。

这种发现方式只能通过使用当前版本的 RTPS 协议来完成。

这种简单的发现形式是通过对运行在应用程序进程中的 DDS 应用程序数据读取器和数据写入器的简单配置来完成的，如图 1-4 所示。

当每个参与进程为其数据读取器和写入器激活 OpenDDS 中的 DDSI-RTPS 发现机制时，使用默认或配置的网络端口创建网络端点，以便 DDS 参与者可以开始宣传其数据读取器和数据写入器的可用性。

一段时间后，那些根据标准相互寻找的人将找到彼此，并根据可扩展传输框架 (ETF) 中讨论的配置的可插拔传输建立连接。在第 7.4.1.1 节和第 7.4.5.5 节中讨论了这种灵活配置方法的更详细描述。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dGl90RQQ-1652410199858)(https://note.youdao.com/yws/res/2991/WEBRESOURCE97d86e139a72c587a19c7a3ec93069db)]

以下是开发人员在开发和部署使用 RTPS 发现的应用程序时需要考虑的其他实施限制：

由于 UDP 端口分配给域 ID 的方式，域 ID 应介于 0 和 231（含）之间。在每个 OpenDDS 流程中，每个域最多支持 120 个域参与者。
主题名称和类型标识符限制为 256 个字符。
由于 GUID 的分配方式，OpenDDS 的本机多播传输不适用于 RTPS 发现（如果尝试这样做，将发出警告）。

有关 RTPS 发现如何发生的更多详细信息，可以在实时发布-订阅有线协议 DDS 互操作性有线协议规范 (DDSI-RTPS) v2.2 的第 8.5 节中找到非常好的阅读参考（OMG 文件正式/2014-09-01）。

Threading

OpenDDS 创建自己的 ORB（当需要时）以及运行该 ORB 的单独线程。

它还使用自己的线程来处理传入和传出的传输 I/O。创建一个单独的线程以在意外连接关闭时清理资源。

您的应用程序可能会通过 DCPS 的侦听器机制从这些线程中回调。通过 DDS 发布样本时，OpenDDS 通常会尝试使用调用线程将样本发送给任何连接的订阅者。如果发送调用阻塞，则样本可能会排队等待在单独的服务线程上发送。此行为取决于第 3 章中描述的 QoS 策略。

订阅者中的所有传入数据都由服务线程读取，并排队等待应用程序读取。从服务线程调用 DataReader 侦听器。

配置

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

Installation

如何构建 OpenDDS 的步骤可以在 $DDS_ROOT/INSTALL.md 中找到。

要使用 DDS 安全性构建 OpenDDS，请参阅下面的第 14.1 节。为避免编译您不会使用的 OpenDDS 代码，有些功能可以排除在构建之外。

下面讨论这些特征。

需要小尺寸配置或与面向安全的平台兼容的用户应考虑使用 OpenDDS 安全配置文件，该配置文件在本指南的第 13 章中进行了描述。

启用或禁用功能的构建配置脚本支持大多数功能

配置脚本创建具有正确内容的配置文件，然后运行MPC。

如果您正在使用配置脚本，请使用“–help”命令行选项运行它并查找您希望启用/禁用的功能。如果您不使用配置脚本，请继续阅读以下有关直接运行 MPC 的说明。对于下面描述的功能，MPC 用于启用（默认）功能或禁用该功能。

对于名为 feature 的功能，使用以下步骤从构建中禁用该功能：

对 MPC 使用命令行“功能”参数：

mwc.pl -type <type> -features feature=0 DDS.mwc

或者，将行 feature=0 添加到文件 $ACE_ROOT/bin/MakeProjectCreator/config/default.features 并使用 MPC 重新生成项目文件。

如果您正在使用 gnuace MPC 项目类型（如果您将使用 GNU make 作为构建系统，就是这种情况），将行“feature=0”添加到文件 $ACE_ROOT/include/makeinclude/platform_macros.GNU。

要显式启用该功能，请使用上面的 feature=1。

注意：您还可以使用 $DDS_ROOT/configure 脚本来启用或禁用功能。要禁用该功能，请将 --no-feature 传递给脚本，以启用 pass --feature。在这种情况下，使用“-”而不是特征名称中的“_”。例如，要禁用下面讨论的功能 content_subscription，请将 --no-content subscription 传递给配置脚本。

禁用内置主题支持的构建

功能名称：built_in_topics

通过禁用内置主题支持，您可以将核心 DDS 库的占用空间减少多达 30%。有关内置主题的描述，请参见第 6 章。

禁用合规配置文件功能的构建

DDS 规范定义了合规性配置文件，以提供一个通用术语来指示 DDS 实现可能支持或可能不支持的某些功能集。

下面给出了这些配置文件，以及用于禁用对该配置文件或该配置文件组件的支持的 MPC 功能的名称。

许多配置文件选项涉及 QoS 设置。如果您尝试使用与禁用的配置文件不兼容的 QoS 值，则会发生运行时错误。如果配置文件涉及类，如果您尝试使用该类并且配置文件被禁用，则会发生编译时错误。

内容订阅配置文件

功能名称：content_subscription 此配置文件添加了第 5 章中讨论的类 ContentFilteredTopic、QueryCondition 和 MultiTopic。此外，可以使用下表中给出的功能排除单个类。

Class	Feature
ContentFilteredTopic	content_filtered_topic
QueryCondition	query_condition
MultiTopic	multi_topic

持久性配置文件

功能名称：persistence_profile

此配置文件添加了 QoS 策略 DURABILITY_SERVICE 以及 DURABILITY QoS 策略类型的设置“TRANSIENT”和“PERSISTENT”。

所有权概况

功能名称：ownership_profile

此配置文件添加：
• OWNERSHIP 类型的设置“EXCLUSIVE”
• 支持 OWNERSHIP_STRENGTH 政策
• 为HISTORY QoS 策略设置深度> 1。

注意：一些用户可能希望排除对独占 OWNERSHIP 策略及其关联的 OWNERSHIP_STRENGTH 的支持，而不影响对 HISTORY 的使用。为了支持这种配置，OpenDDS 还具有 MPC 特性 owner_kind_exclusive（配置脚本选项 --no-ownership-kind-exclusive）。

对象模型配置文件

功能名称：object_model_profile

此配置文件包括对“GROUP”的 PRESENTATION access_scope 设置的支持。

注意:目前，禁用 object_model_profile 时，也会排除“TOPIC”的 PRESENTATION access_scope。

构建使用 OpenDDS 的应用程序

本节适用于任何直接或间接包含 OpenDDS 标头的 C++ 代码。对于 Java 应用程序，请参阅下面的第 10 章。包含 OpenDDS 标头的 C++ 源代码可以使用以下任一构建系统构建：MPC 或 CMake。

MPC：Makefile、项目和工作区创建者

OpenDDS 本身是使用 MPC 构建的，因此设置为使用 OpenDDS 的开发系统已经具有 MPC 可用。 OpenDDS 配置脚本创建一个带有环境设置的“setenv”脚本（Windows 上的 setenv.cmd；Linux/macOS 上的 setenv.sh）。

此环境包含使用 MPC 所需的 PATH 和 MPC_ROOT 设置。 MPC 的源代码树（在 MPC_ROOT 中）包含一个“docs”目录，其中包含 HTML 和纯文本文档（USAGE 和 README 文件）。

2.1 节中的示例演练使用 MPC 作为其构建系统。 OpenDDS 源代码树包含许多使用 MPC 构建的测试和示例。这些可以用作应用程序 MPC 文件的起点。

cmake

应用程序也可以使用 CMake ( https://cmake.org) 构建。

请参阅 OpenDDS 源代码树中包含的文档：docs/cmake.md

OpenDDS 源代码树还包括使用 CMake 的示例。它们列在 cmake.md 文件中。

自定义构建系统

强烈建议 OpenDDS 的用户选择上面列出的两个选项之一（MPC 或 CMake），以便在任何受支持的平台上生成一致的构建文件。如果无法做到这一点，OpenDDS 的用户必须确保自定义构建设置中的所有代码生成器、编译器和链接器设置都生成与 API 和 ABI 兼容的代码。

为此，请从 MPC 或 CMake 生成的项目文件（makefile 或 Visual Studio 项目文件）开始，并确保在自定义构建系统中表示所有相关设置。这通常通过检查项目文件和运行带有详细输出的构建的组合来完成，以查看工具链（代码生成器、编译器、链接器）是如何被调用的。

通过 https://objectcomputing.com/products/opendds/consultingsupport 联系 Object Computing, Inc. (OCI)，让我们的专业软件工程师为您解决此问题。