车载通信与DDS标准解读系列（4）：DDSI-RTPS协议

▎什么是RTPS

在DDS协议中，主要描述了实现数据分发服务的DCPS模型和QoS策略，但是我们还不清楚数据怎样在网络中传输，想要了解这些内容，就需要请出咱们的数据搬运工——RTPS。

RTPS全称是Real-Time Publish-Subscribe Protocol，实时发布订阅协议，定义了DDS基于有线传输的通信行为、报文格式等内容。

RTPS的主要特点包括：

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

RTPS对底层传输要求：

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

▎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：可能与对数据对象所做的更改相关联的数据

Messages 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相互发现。两者都是基本的发现协议。

▎结语

通过对RTPS协议的解析，我们了解到RTPS作为DDS的互操作性有线协议，定义了底层的交互方式及报文格式。协议主要分为四个部分：（1）Structure Module（描述了RTPS类与属性以及与DDS关联）；(2) Message Module（描述了RTPS报文结构和子消息类型）(3) Behavior Module（描述了RTPS stateless和stateful状态的 writer和reader分别实现Reliable和Best-Effort通信的行为）(4) Discovery Module（分别定义了SPDP和SEDP两个简单发现协议）。更多有关DDS子协议的内容，会在后续文章中为大家进行介绍，敬请期待。