OMG--RTPS（Real Time Publish Subscribe Protocol）
OMG--RTPS（Real Time Publish Subscribe Protocol）
- 1 概述
- 2 内容
-
- 缩写
- DDS 有线协议的要求
- RTPS 有线协议
- The RTPS Platform Independent Model (PIM)
-
- The Structure Module
- The Messages Module
- The Behavior Module
- The Discovery Module
- The RTPS Platform Specific Model (PSM)
- The RTPS Transport Model
- Platform Independent Model (PIM)【详解】
-
- 介绍
- Structure Module（结构模块）
-
- 主要的类
- RTPS Entities and Classes
- Summary of the types used to describe RTPS Entities and Classes
- Configuration attributes of the RTPS Entities
- The RTPS HistoryCache
- The RTPS CacheChange
- The RTPS Entity（实体）
- The RTPS Participant（参与者）
- The RTPS Group
- The RTPS Endpoint（端点）
- The RTPS Writer
- The RTPS Reader
- Relation to DDS Entities
- Messages Module（消息模块）
-
- Type Definitions 类型定义
- RTPS消息的整体结构
- The RTPS Message Receiver
- RTPS SubmessageElements
- RTPS Submessages
- Behavior Module（行为模块）
-
- 一个典型的时序
- 互操作性所需的行为
- 符号约定
- RTPS Writer 参考实现
- RTPS StatelessWriter 行为
- RTPS StatefulWriter 行为
- RTPS Reader 参考实现
- RTPS StatelessReader 行为
- RTPS StatefulReader 行为
- Discovery Module（发现模块）
-
- RTPS 内置发现端点
- SPDP
- 简单参与者发现协议
- 简单端点发现协议
- Platform Specific Model (PSM): UDP/IP（详解）
-
- 符号约定
-
- 结构的 IDL 表示和 CDR wire 表示
- 位和字节的表示
- 3 补充
- 参考
1 概述
如下介绍，OMG组织定义的RTPS（Real Time Publish Subscribe Protocol），实时发布订阅协议。
Version: 2.5
OMG Document Number: formal/2022-04-01
Standard document URL: https://www.omg.org/spec/DDSI-RTPS/2.5/PDF
2 内容
缩写
| 缩写 | 含义 | 备注 |
|---|---|---|
| CDR | Common Data Representation | 通用数据表示 |
| DDS | Data Distribution Service | 数据分发服务 |
| EDP | Endpoint Discovery Protocol | 端点发现协议 |
| GUID | Globally Unique Indentifier | 全局唯一标识符 |
| PDP | Participant DiscoveryProtocol | 参与者发现协议 |
| PIM | Platform Independent Model | 平台独立模型 |
| PSM | Platform Specific Model | 平台专用模型 |
| RTPS | Real-Time Publish-Subscribe | 实时发布订阅 |
| SEDP | Simple Endpoint Discovery Protocol | 简单端点发现协议 |
DDS 有线协议的要求
- 网络通信的工程设计是关于做出正确的权衡，而这些权衡必须平衡冲突，诸如通用性、易用性、功能丰富性、性能、内存大小和使用等要求；可伸缩性、确定性和健壮性。这些权衡必须根据信息流的类型来进行，以及应用程序和执行平台施加的约束。
- 许多成功的协议，如HTTP、SOAP、FTP、DHCP、DCE、RTP、DCOM、和CORBA。这些协议中的每一个都填补了一个空缺，为特定的目的或应用提供了良好的功能。
- DDS的基本通信模型是一种单向数据交换模型，发布数据将相关数据更新“推送”到位于同一位置的数据订阅者的本地缓存。这信息流由隐含地建立在 DataWriters 和 DataReaders 之间的QoS契约来调节。DataWriter在声明其发布数据的意图时指定其QoS契约，DataReader在声明订阅数据的意图时执行此操作。
- 典型的交流模式，包括多对多样式配置。部署DDS技术的应用程序的主要关注点是以最小的开销以有效的方式分发信息。另一个重要要求需要以健壮的容错方式扩展到数百或数千个订阅者。
- DDS规范规定了内置发现服务的存在，该服务允许发布者动态发现订阅者的存在，反之亦然，并连续执行此任务，不需要联系任何域名服务器。
RTPS 有线协议
实时发布订阅 (RTPS) 协议起源于工业自动化，实际上已被 IEC 批准为实时工业以太网套件 IEC-PAS-62030 的⼀部分。这是⼀项经过现场验证的技术，目前在全球范围内部署在数千台工业设备中。
RTPS协议被设计成能够在多播和无连接的尽力而为传输上运行，例如UDP / IP。RTPS协议的主要特性包括:
- 性能和服务质量的属性，使尽最大努力和可靠的发布订阅通信的实时应用程序在标准的IP网络。
- 容错，允许创建没有单点故障的网络。
- 可扩展性，允许协议扩展和增强新的服务，而不需要破坏向后兼容性和互操作性。
- 即插即用连接，以便自动发现新的应用程序和服务应用程序可以随时加入和离开网络，而无需重新配置。
- 可配置性，以平衡每个数据的可靠性和及时性要求交付。
- 模块化，允许简单的设备实现协议的一个子集，仍然参与网络。
- 可扩展性，使系统能够扩展到非常大的网络。
- 类型安全，防止应用程序编程错误危及操作远程节点。
The RTPS Platform Independent Model (PIM)
RTPS协议用一个平台无关模型(PIM)和一组psm来描述。RTPS PIM包含四个模块：结构、消息、行为和发现。
- 结构模块定义通信端点。
- Messages模块定义了这些端点的消息集可以交换。
- Behavior模块定义了一组合法的交互(消息交换)以及它们的影响方式通信端点的状态。换句话说，Structure模块定义了协议“参与者”，消息模块是一组“语法符号”，行为模块是法律语法和不同对话的语义。
- Discovery模块定义实体如何自动出现已发现并配置。
在PIM中，消息是根据其语义内容定义的。然后可以将此PIM映射到各种平台特定模型(psm)，如普通UDP或corba事件。
The Structure Module
本规范使用了许多与DDS规范中使用的核心实体相同。如图所示，所有RTPS实体都是与RTPS域相关联，RTPS域表示一个单独的通信平面，其中包含一组参与者。参与者包含包含本地端点的组。端点有两种：reader和writer。reader和writer是通过发送RTPS来进行信息通信的参与者消息。写入器通知域的存在，并将域上本地可用的数据发送给读取器可以请求和确认数据。
RTPS协议中的参与者与DDS实体是一对一的关系。
The Messages Module
- messages 模块定义了 RTPS Writers 和 Readers 之间的原子信息交互内容。
- 消息由一个 Header 后跟一些 Submessages 组成，如图所示，每个 Submessage 都是由一系列 Submessage 元素构建的。
- 选择这种结构是为了允许 Submessages 的词汇和每个 SubMessage 的组成，在保持向后兼容性的同时进行扩展。
- HeaderExtension 是一个特殊的Submessage，可以选择出现在 Header 之后。
The Behavior Module
Behavior 模块描述了允许的消息序列，这些消息可以在 RTPS Writer 和 Reader 之间交换，以及每条消息引起的 Writer 和 Reader 状态的时间和变化。
The Discovery Module
发现模块描述了使参与者能够获取有关域中所有其他参与者和端点的存在和属性的信息的协议。 这个元流量使
每个 Participant 获取域中所有 Participant、Reader 和 Writers 的完整图片，并配置本地 Writers 与远程 Reader 通信，本地 Reader 与远程 Writers 通信。
发现是一个单独的模块。 Discovery 的独特需求，即关联匹配的写入器和读取器所需的所有信息的透明即插即用传播，使得单一架构或协议不太可能满足各种不同的可扩展性、性能和可嵌入性的极端可变需求 将部署 DDS 的异构网络。 从今以后，引入多种发现机制是有意义的，从简单高效（但可扩展性不强）到更复杂的分层（但可扩展性更高）机制。
The RTPS Platform Specific Model (PSM)
- 平台特定模型将 RTPS PIM 映射到特定的底层平台。
- 它为所有 RTPS 类型和消息以及任何其他特定信息定义了平台上 bits 和 bytes 的精确表述。
- 可能支持多个 PSM，但 DDS 的所有实现必须有在 UDP/IP 之上的 PSM。
The RTPS Transport Model
RTPS 支持多种传输和传输 QoS。
Platform Independent Model (PIM)【详解】
介绍
本节为 RTPS 协议定义了平台独立模型（PIM）。随后描述将 PIM 映射到各种平台，最基本的平台是本机 UDP 数据包。PIM 用“virtual machine”来描述协议。
Structure Module（结构模块）
RTPS 实体是应用程序可见的 DDS 实体使用的协议级端点，以便相互沟通。
每个 RTPS 实体都与一个 DDS 实体一一对应。
主要的类
所有 RTPS 实体都派生自 RTPS 实体类。
RTPS Entities and Classes
| class | Purpose | 翻译 |
|---|---|---|
| Entity | Base class for all RTPS entities. RTPS Entity represents the class of objects that are visible to other RTPS Entities on the network. As such, RTPS Entity objects have a globally-unique identifier (GUID) and can be referenced inside RTPS messages. | 所有 RTPS 实体的基类。 RTPS 实体表示对象的类对网络上的其他 RTPS 实体可见。 因此，RTPS 实体对象具有全局唯一标识符 (GUID)，可以在 RTPS 消息中引用。 |
| Endpoint | Specialization of RTPS Entity representing the objects that can be communication endpoints. That is, the objects that can be the sources or destinations of RTPS messages. | 表示可以作为通信端点的对象的 RTPS 实体的特化。 即，可以作为 RTPS 消息的源或目标的对象。 |
| Participant | Container of all RTPS entities that share common properties and are located in a single address space. | 所有 RTPS 实体的容器，这些实体共享共同的属性并且位于单一地址空间。 |
| Writer | Specialization of RTPS Endpoint representing the objects that can be the sources of messages communicating CacheChanges. | RTPS 端点的特化表示可以作为通信 CacheChanges 的消息源的对象。 |
| Reader | Specialization of RTPS Endpoint representing the objects that can be used to receive messages communicating CacheChanges. | RTPS 端点的特化表示可用于接收通信 CacheChanges 的消息的对象。 |
| HistoryCache | Container class used to temporarily store and manage sets of changes to data-objects. On the Writer side it contains the history of the changes to data-objects made by the Writer. It is not necessary that the full history of all changes ever made is maintained. Rather what is needed is the partial history required to service existing and future matched RTPS Reader endpoints. The partial history needed depends on the DDS QoS and the state of the communications with the matched Reader endpoints. On the Reader side it contains the history of the changes to data-objects made by the matched RTPS Writer endpoints. It is not necessary that the full history of all changes ever received is maintained. Rather what is needed is a partial history containing the superposition of the changes received from the matched writers as needed to satisfy the needs of the corresponding DDS DataReader. The rules for this superposition and the amount of partial history required depend on the DDS QoS and the state of the communication with the matched RTPS Writer endpoints. | 用于临时存储和管理数据对象更改集的容器类。 在 Writer 端，它包含 Writer 对数据对象所做更改的历史记录。 没有必要保留所有更改的完整历史记录。 相反，需要的是为现有和未来匹配的 RTPS 阅读器端点提供服务所需的部分历史记录。 所需的部分历史记录取决于 DDS QoS 以及与匹配的阅读器端点的通信状态。 在 Reader 端，它包含匹配的 RTPS Writer 端点对数据对象所做更改的历史记录。 没有必要维护曾经收到的所有更改的完整历史记录。 相反，需要的是部分历史记录，其中包含根据需要从匹配的写入器接收到的更改的叠加，以满足相应 DDS DataReader 的需要。 这种叠加的规则和所需的部分历史量取决于 DDS QoS 和与匹配的 RTPS Writer 端点通信。 |
| CacheChange | Represents an individual change made to a data-object. Includes the creation, modification, and deletion of data-objects. | 表示对数据对象所做的单独更改。 包括数据对象的创建、修改和删除。 |
| Data | Represents the data that may be associated with a change made to a data-object. | 表示可能与对数据对象所做的更改相关联的数据。 |
Summary of the types used to describe RTPS Entities and Classes
Configuration attributes of the RTPS Entities
The RTPS HistoryCache
HistoryCache 是 DDS 和 RTPS 之间接口的一部分。
The RTPS CacheChange
The RTPS Entity（实体）
The GUID (Globally Unique Identifier) is an attribute of all RTPS Entities and uniquely identifies the Entity
within a DDS Domain.
The RTPS Participant（参与者）
RTPS Participant 是包含 Endpoint 实体的 RTPS Group 实体的容器。 RTPS Participant 映射到 DDS DomainParticipant。
The RTPS Group
RTPS Group 是 RTPS Endpoint 实体的容器。 它为 RTPS 端点实体提供了一种共享公共属性的方法。
有两种 RTPS Group 实体：Publisher 和 Subscriber。
The RTPS Endpoint（端点）
RTPS Endpoint 表示从 RTPS 协议的角度来看可能的通信端点。有两种 RTPS 端点实体：Writer 端点和 Reader 端点。
RTPS 编写器端点将 CacheChange 消息发送到 RTPS 读取器端点，并可能收到对它们发送的更改的确认。 RTPS Reader 端点从 Writer 端点接收 CacheChange 和 changeavailability 公告，并可能确认更改和/或请求
错过的变化。
The RTPS Writer
RTPS Writer 特化 RTPS Endpoint 并代表将 CacheChange 消息发送到匹配的 RTPS Reader 端点的参与者。 它的作用是将其 HistoryCache 中的所有 CacheChange 更改传输到匹配的远程 RTPS Reader 的 HistoryCache。
The RTPS Reader
RTPS Reader 特化 RTPS Endpoint 并表示从匹配的 RTPS Writer 端点接收 CacheChange 消息的参与者。
Relation to DDS Entities
HistoryCache 构成了 DDS 实体与其对应的 RTPS 实体之间的接口。 例如，DDS DataWriter 通过公共 HistoryCache 将数据传递到其匹配的 RTPS Writer。
下面的状态图说明了 DDS 数据写入器如何向 HistoryCache 添加更改。
下面的状态图说明了 DDS 数据读取器如何获取 HistoryCache 的变化。
Messages Module（消息模块）
Messages 模块描述了在 RTPS Writer 端点和 RTPS Reader 端点之间交换的消息的整体结构和逻辑内容。 RTPS 消息在设计上是模块化的，可以轻松扩展以支持标准协议功能添加以及供应商特定的扩展。
Type Definitions 类型定义
RTPS消息的整体结构
- messages 模块定义了 RTPS Writers 和 Readers 之间的原子信息交互内容。
- 消息由一个 Header 后跟一些 Submessages 组成，如图所示，每个 Submessage 都是由一系列 Submessage 元素构建的。
- 选择这种结构是为了允许 Submessages 的词汇和每个 SubMessage 的组成，在保持向后兼容性的同时进行扩展。
- HeaderExtension 是一个特殊的Submessage，可以选择出现在 Header 之后。
RTPS 标头必须出现在每条消息的开头。
HeaderExtension 可以选择紧跟在 Header 之后。在不破坏与早期版本 RTPS 协议的互操作性的情况下
，它在标头中扩展了信息。
Submessage 结构：
The RTPS Message Receiver
RTPS SubmessageElements
每个 RTPS 消息包含可变数量的 RTPS 子消息。
RTPS Submessages
Behavior Module（行为模块）
该模块描述了 RTPS 实体的动态行为。 它描述了 RTPS Writer 端点和 RTPS Reader 端点之间消息交换的有效序列以及这些消息的时序约束。
一旦 RTPS Writer 与 RTPS Reader 匹配，它们都负责确保将存在于 Writer 的 HistoryCache 中的 CacheChange 更改传播到 Reader 的 HistoryCache。
行为模块描述匹配的 RTPS Writer and Reader对，必须配合传递 CacheChange 的更改。
一个典型的时序
一个典型的序列说明RTPS Writer 和匹配的 RTPS Reader 之间的交互。
互操作性所需的行为
⼀般要求:
- 所有通信都必须使用 RTPS 消息进行
- 所有实现都必须实现 RTPS 消息接收器
- 所有实现的时序特性必须是可调的
- 实施必须实施简单参与者和端点发现协议
所需的 RTPS 编写器行为
- 写入者不得乱序发送数据
- 如果读者请求，编写者必须包括在线 QoS 值
- Writers必须定期发送 HEARTBEAT 消息（仅限可靠）
- Writers最终必须回应否定的承认（仅可靠）
- 使用Writer组信息发送心跳和间隙
所需的 RTPS 阅读器行为
- 读者必须在收到未设置最终标志的 HEARTBEAT 后做出最终响应
- 读者必须在收到指示样本丢失的心跳后做出最终回应
- ⼀旦承认，永远承认
- 读者只能发送 ACKNACK 消息以响应 HEARTBEAT 消息
符号约定
RTPS Writer 参考实现
RTPS Writer 特化 RTPS Endpoint 并代表将 CacheChange 消息发送到匹配的 RTPS Reader 端点的参与者。 Reference Implementations StatelessWriter 和 StatefulWriter 专门用于 RTPS Writer，并且在它们维护的关于匹配的 Reader 端点的知识方面有所不同。
RTPS StatelessWriter 行为
RTPS StatefulWriter 行为
RTPS Reader 参考实现
RTPS StatelessReader 行为
RTPS StatefulReader 行为
Discovery Module（发现模块）
发现协议的目的是允许每个 RTPS 参与者发现其他相关参与者及其端点。 一旦远程端点已经发现，实现可以相应地配置本地端点以建立通信。
DDS 规范同样依赖于使用发现机制来建立通信匹配的 DataWriters 和 DataReaders。 DDS 实现必须自动发现远程实体，无论是在他们加入和离开网络时。
RTPS 规范将发现协议拆分为两个独立的协议：（大型网络的基本发现协议。）
- Participant Discovery Protocol（PDP）【参与者发现协议】
- Endpoint Discovery Protocol（EDP）【端点发现协议】
为了互操作性，所有 RTPS 实现必须至少提供以下发现协议：（中小型网络的基本发现协议。）
- Simple Participant Discovery Protocol （SPDP）
- Simple Endpoint Discovery Protocol （SEDP）
每个RTPS StatelessWriter关联RTPS ReaderLocator对象。
每个RTPS StatefulWriter关联RTPS ReaderProxy对象。
每个RTPS StatefulReader关联RTPS WriterProxy对象。
RTPS 内置发现端点
有四个预定义的内置主题：“DCPSParticipant”、“DCPSSubscription”、“DCPSPublication”和“DCPSTopic”。 与这些主题关联的数据类型也由 DDS 规范指定，并且主要包含实体 QoS 值。
SPDP 关注参与者如何发现彼此，将 DDS 内置实体映射到 “DCPSParticipant”主题。 SEDP，指定如何在本地交换发现信息主题、DataWriters 和 DataReaders，为“DCPSSubscription”、“DCPSPublication”和“DCPSTopic”主题映射 DDS 内置实体。
SPDP
SPDP对每个Participant预留两个内置Endpoint：SPDPbuiltinParticipantWriter 和SPDPbuiltinParticipantReader。
SPDPbuiltinParticipantWriter是一个best-effort的 StatelessWriter，不进行可靠传输且不维护Reader的接收状态。它周期性地向预先配置好的一系列locators（目标地址，多播或者单播地址）交换其HistoryCache里的SPDPdiscoveredParticipantData数据。
SPDPbuiltinParticipantWriter不断发布自己当前发现了的Participant，然后将自己发现的信息和其他人交换，这样每个Participant逐渐就都知道对方了。
简单参与者发现协议
简单端点发现协议
Platform Specific Model (PSM): UDP/IP（详解）
符号约定
结构的 IDL 表示和 CDR wire 表示
typedef octet OctetArray3[3];
struct EntityId_t {
OctetArray3 entityKey;
octet entityKind;
};
位和字节的表示
经常使用以下符号来表示八位字节或字节：
+-+-+-+-+-+-+-+-+
|7|6|5|4|3|2|1|0|
+-+-+-+-+-+-+-+-+
在这种表示法中，最左边的位（第 7 位）是最高有效位（“MSB”），最右边的位（第 0 位）是最低有效位（“LSB”）。
字节流按每行 4 个字节排序，如下所示：
0...2...........7...............15.............23. .............31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first byte | | | 4th byte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-----------stream------------->>>>
在此表示中，流中最先出现的字节位于左侧。 最左边的位是第一个字节的 MSB； 最右边的位是第 4 个字节的 LSB。
3 补充
参考
1、DDS RTPS PDF
2、RTPS规范
3、实时发布 - 订阅（RTPS）
4、【DDS】DDSI-RTPS规范
5、DDSI-RTPS v2.5 译文 CH8 PIM 8.5 发现模块
6、【ROS2概念】系列(四)——DDS中间件架构详细解析
7、使用Fast DDS Discovery Server作为发现协议
8、Fast RTPS原理与代码分析(2)：动态发现协议之参与者发现协议PDP