DDS（Data Distribution Service） 数据分发服务-02 RTPS

DDS（Data Distribution Service） 数据分发服务-02 RTPS

---

---

前言

上一篇讲到DDS标准中，包含了很多子协议，其中最重要的核心协议主要有两个：DDS和RTPS。
DDS：描述了用于分布式应用程序通信和集成的以数据为中心的发布-订阅 (DCPS) 模型。该规范定义了应用程序接口 (API) 和通信语义（行为和服务质量），它们能够有效地将信息从信息生产者传递到匹配的消费者。DDS 规范的目的可以概括为“在正确的时间将正确的信息高效、稳健地传递到正确的地点”。
RTPS：（Real Time Publish Subscribe Protocol）协议通过TCP/UDP等实现最大努力可靠的发布-订阅，属于传输层协议。该规范定义了 DDS 的互操作性协议，其目的和范围是确保基于不同供应商的 DDS 实现的应用程序可以互操作。
本文主要介绍RTPS的基本情况。

---

一、什么是RTPS？

DDS的标准中并不包含传输层协议，所以不同厂家实现的DDS可能使用不同的消息交互方式，甚至使用不同的传输协议，这就可能导致来自不同厂家的DDS实现是不能互操作的。而随着DDS在大型分布式系统中的应用越来越广泛，制定统一传输层标准的需求越来越强烈。
RTPS（Real-Time Publish Subscribe）就是在此背景下诞生，它主要为了满足工业自动化领域大规模分布式系统的需求，也能够很好的契合DDS协议特点。规范中定义了消息格式，各种使用场景下的消息交互方式等。它的主要特点包括：

• 支持QoS，可实现实时应用程序之间Best-Effort和Reliable两类通信
• 容错性，允许创建没有单点故障的网络，不依赖集中式服务器
• 可扩展性，允许复杂设备通过新的服务进行扩展，而不破坏向后兼容性和互操作性
• 即插即用，应用程序之间通过自动发现机制，可随时加入或离开网络，而不需要重新配置
• 模块化，允许简单设备实现协议的部分功能，仍可以参与网络通信

RTPS对底层传输要求：

• 应存在广义概念上的单播地址（16Byte以内）
• 具有端口广义概念（4B），可以是UDP端口，也可以是共享内存段等等
• 可以将数据包（具有序列号）发送特定地址/端口
• 可以在一个特定的地址/端口上接收一个数据包
• 消息在传输过程中不完整或者损坏，RTPS将删除消息，即RTPS假设消息完整且未损坏

RTPS基于多播、无连接的传输模型，这个模型可以映射到不同的传输协议上，如UDP/IP（这也是目前RTPS标准中唯一被标准化的传输协议）。除此之外，基于TCP的传输，以及基于TSN（Time-Sensitive Networks）的传输的相关标准也在制定中。很多DDS的实现支持除UDP/IP之外的多种传输协议，但并没有遵循统一的标准，因此不同供应商的DDS实现之间可能存在互操作问题。

二、RTPS组成

RTPS定义了四部分内容，分别为：

• Structure Module：定义了RTPS entity和DDS entity之间的映射关系，以及用于数据交互的通信端点
• Message Module：定义了通信端点之间交互的报文格式
• Behavior Module：定义了通信端点之间的交互行为
• Discovery Module：定义了RTPS entity之间如何自动发现和配置

structure Module

Structure Module 描述了作为通信参与者的RTPS实体的结构，如下图所示，RTPS实体是被应用程序可见的DDS实体相互通信而使用的协议级端点。

Entity：所有RTPS实体的基类, 每一个RTPS实体对象都具有一个全局唯一标识符(GUID)，GUID可以在RTPS消息中进行体现
Endpoint：RTPS实体对象的通信端点，可以是RTPS消息的源或目标的对象
Participant：在一个独立地址空间中的所有RTPS实体的容器，共享公共属性
Writer：RTPS的Endpoint，表示传递数据更改消息的发送端
Reader：RTPS的Endpoint，表示传递数据更改消息的接收端
HistoryCache：用于临时存储和管理对数据对象的更改集的容器类
CacheChange：对数据对象所做的更改。包括对数据对象的创建、修改和删除
Data：可能与对数据对象所做的更改相关联的数据

Message Module

Messages模块描述了在RTPS Writer端点和RTPS Reader端点之间交换的消息的总体结构和逻辑内容，其结构如下所示。

RTPS消息的整体结构由固定大小的RTPS头部(Header)和可变数量的RTPS子消息部分组成。子消息的种类包括HeaderExtension、Data、DataFrag、Heartbeat、HeartbeatFrag、AckNack、NackFrag、Gap、InfoDestination、InfoSource、InfoReply、InfoTimestamp、Pad，每个子消息的报文格式依次由一个SubmessageHeader和一个可变数量的SubmessageElement组成。每个部分的作用如下：

Header：该报头用于标识RTPS报文，携带RTPS协议版本、供应商和GUID前缀等信息，其报文格式如下：

HeaderExtension：可以添加在Header字段之后。它扩展了报头中提供的信息，同时还能保持和以往RTPS协议版本的兼容。

Data：由RTPS Writer发给RTPS Reader，告知对端有数据更新，其报文格式如下：

DataFrag：由RTPS Writer发给RTPS Reader，告知对端有数据更新，且需在RTPS Reader端对分片数据进行重组。

Heartbeat：由RTPS Writer发给RTPS Reader，告知当前的可用数据，其报文格式如下：

HeartbeatFrag：由RTPS Writer发给RTPS Reader，告知对端当前可用的数据分段。
AckNack：由RTPS Reader发给RTPS Writer，告知已接收/未接收的数据，其报文格式如下：

NackFrag：由RTPS Reader发给一个或多个RTPS Writer，告知对端当前仍未收到的数据分段
Gap：由RTPS Writer发给RTPS Reader ，告知未发送的过滤掉的数据
InfoDestination：由RTPS Writer发给RTPS Reader，告知后续报文的GuidPrefix需依据该子消息更新
InfoSource：由RTPS Writer发给RTPS Reader，告知Reader协议Version，VendorID有更新
InfoReply：由RTPS Reader发给RTPS Writer，告知回复子消息的目标地址需依据该子消息更新
InfoTimestamp：告知同一RTPS报文的后续Submessage的时间戳
Pad：用于在需要内存对齐时进行padding

Behavior Module

该模块描述了RTPS实体的动态行为。它描述了RTPS Writer端点和RTPS Reader端点之间报文交换的有效序列和时间约束。

根据本地端点是否维持远端匹配端点的数据收发状态，RTPS规范定义了两种参考实现:

• 无状态参考实现（Stateless Reference Implementation）:无状态参考实现不保留远程实体的状态，因此可以很好地扩展到大型系统。无状态参考实现非常适合通过多播进行Best-Effort通信
• 有状态参考实现（Stateful Reference Implementation）:有状态参考实现维护远程实体的完整状态。这种方法可以尽可能地减少带宽使用，但需要更多内存。与无状态参考实现相比，它可以保证Reliable通信，并且能够在Writer端应用基于QoS或基于内容的过滤

RTPS Writer参考实现基于RTPS Writer类的特定实例化，分为Stateless Writer和Stateful Writer。

• Stateless Writer不知道匹配的Reader的数量，也不为每个匹配的RTPS Reader端点维护任何状态，只维护RTPS ReaderLocator列表，该列表应用于向匹配的读取器发送信息
• Stateful Writer配置了所有匹配的RTPS Reader端点的信息，并维护每个匹配的RTPS Reader端点的状态，以确定是否所有匹配的RTPS Reader端点都收到了特定的数据。对于Best-Effort通信，Writer在收到上层APP下发的数据后即可发出；对于Reliable通信，Writer还需依据接收到的ACKNACK子消息判断是否重发数据。

RTPS Reader参考实现基于RTPS Reader类的特定实例化，分为Stateless Reader和Stateful Reader。

• Stateless Reader不知道匹配的Writer的数量，也不为每个匹配的RTPS Writer维护任何状态。
• Stateful Reader保存每个匹配的RTPS Writer的状态。对于Best-Effort通信，Reader收到数据后放入本地缓存即可；对于Reliable通信，Reader需依据已接收/未接收的数据状态选择性发送ACKNACK子消息进行确认/重发请求。

StatefulWriter + StatefulReader + Reliable的RTPS交互示例如下图所示，StatefulWriter需要创建ReaderProxy,记录匹配的StatefulReader的端点信息，当上层有更新的数据时，把更新的数据发给StatefulReader，StatefulReader需要创建WriterProxy，依据Data/Heartbeat子消息在WriterProxy中记录数据的接收状态，然后回复AckNack子消息，StatefulWriter根据接收到的AckNack子消息，在ReaderProxy中更新数据的接收状态，若StatefulReader存在未接收的数据，则重发该数据。

Discovery Module

RTPS Behavior模块假设RTPS端点已正确配置，并与匹配的远程端点完成匹配。但是没有对这个配置是如何发生的做任何假设，只是定义了如何在这些端点之间交换数据。因此Discovery模块定义了RTPS的发现协议，目的是允许每个RTPS参与者发现其他相关参与者及其端点。一旦发现了远程端点，就可以相应地配置本地端点以建立通信。用户可以通过DDS内置主题访问此发现信息。

RTPS规范将发现协议拆分为两个独立的协议:

• 参与者发现协议（PDP）
• 端点发现协议（EDP）

参与者发现协议（PDP）指定参与者（Participant）如何在网络中发现彼此。一旦两个参与者（Participant）发现了对方，他们就会使用端点发现协议（EDP）交换关于所包含的端点（Endpoint的）信息。除了这种先发现Participant、再发现Endpoint的先后关系之外，这两种方案都可以被认为是独立的。

实现RTPS可以选择支持多个PDP和EDP，为了实现互操作性，所有RTPS实现必须至少提供以下发现协议:

• 简单参与者发现协议(SPDP)：用于RTPS Participant相互发现
• 简单端点发现协议(SEDP)：用于RTPS Writer/Reader相互发现。两者都是基本的发现协议

以上章节参考：https://zhuanlan.zhihu.com/p/678647723