实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_002

实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_002

关键字：OMG，RTPS，DDS

The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification，Version 2.2，September 2014

7 概述

7.4 RTPS平台无关模型（PIM）

根据平台无关模型（PIM）和一组PSM描述RTPS协议。

RTPS PIM包含四个模块：结构，消息，行为和发现。结构（Structure）模块定义通信端点。 消息（Messages）模块定义这些端点可以交换的消息集合。行为（Behavior）模块定义了合法交互集（消息交换）以及它们如何影响通信端点的状态。换句话说，Structure模块定义了协议“参与者”，Messages模块定义了“语法符号”，而Behavior模块定义了不同会话的合法语法和语义。发现（Discovery）模块定义如何自动发现和配置实体。

图 7.1 RTPS模块

在PIM中，消息是根据其语义内容定义的。可以将此PIM映射到各种平台特定模型（PSM）中，例如普通UDP或CORBA事件。

7.4.1 结构模块

鉴于其发布订阅的根源，RTPS自然地映射到多个DDS概念中。本规范会使用许多DDS规范已经使用的相同核心实体。如图1.2所示，所有RTPS实体都与RTPS域相关联，RTPS域表示包含一组参与者（Participants）的单独通信平面。 参与者包含本地端点（Endpoints）。 有两种类型的端点：读取者（Readers）和写入者（Writers）。读取者和写入者是通过发送RTPS消息来传达信息的参与者。写入者告知数据的存在并将**数据域（Domain）**上的本地可用数据发送给读取者，读取者可以请求和确认数据。

图 7.2 RTPS结构模块

RTPS协议中的活动者与DDS实体一一对应，这是通信产生的原因。如图7.3所示。

图 7.3 RTPS与DDS对应关系

结构模块在8.2中描述。

7.4.2 消息模块

消息模块定义RTPS写入者和读取者之间的原子信息交换的内容。消息（Message）由一个报文头（Header）后跟一些子消息（Submessage）组成，如图2.4所示。每个消息都是由一系列元素构建的。选择此结构是为了允许扩展子消息的内容和每个子消息的组成，同时保持向下兼容性。

图 7.4 RTPS消息模块

消息模块将在8.3中详细讨论。

7.4.3 行为模块

行为模块描述了可以在RTPS写入者和读取者之间交换的消息序列，以及时间和每条消息引起的写入者和读取者状态的变化。

互操作性所需的行为是根据实现必须遵循的最小规则集来描述的，以便实现互操作。实际实现可能表现出超出这些最低要求的不同行为，具体取决于他们希望如何权衡扩展性，内存要求和带宽使用。

为了说明这个概念，行为模块定义了两个参考实现。一个参考实现基于有状态写入者（StatefulWriters）和有状态读取者（StatefulReaders），另一个基于无状态写入者（StatelessWriters）和无状态读取者（StatelessReaders），如图2.2所示。两种参考实现都满足互操作的最低要求，因此可以互操作，但由于它们存储在匹配的远程实体上的信息不同，因此表现出略微不同的行为。 RTPS协议的实际实现的行为可以是参考实现的完全匹配或组合。

行为模块在8.4中描述。

7.4.4 发现模块

发现模块描述了使参与者（Participants）能够获取域中所有其他参与者（Participants）和端点（Endpoints）的存在和属性信息的协议。这种元通信（metatraffic）使每个参与者（Participant）能够获得域中所有参与者（Participants），读取者（Readers）和写入者（Writers）的完整信息，并配置本地写入者与远程读取者进行通信，以及本地读取者与远程写入者进行通信。

发现是一个单独的模块。发现的独特需求，即写入者和读取者进行匹配所需的所有信息需要通过透明地即插即用传播，使得单个架构或协议不可能满足各种各样的可扩展性，性能和将部署DDS的异构网络的嵌入性需求。从此以后，引入多种发现机制是有意义的，这些机制从简单和有效（但不是很可扩展）到更复杂的分层（但更具可扩展性）机制。

发现模块在8.5中描述

7.5 RTPS平台特定模型（PSM）

特定于平台的模型将RTPS PIM映射到特定的底层平台。它定义了所有RTPS类型和消息的位和字节的精确表示以及专属于平台的其他信息。

可能支持多个PSM，但DDS的所有实现必须在UDP/IP之上实现PSM，这在第3章中介绍。

7.6 RTPS传输模型

RTPS支持各种传输方式和传输QoS。该协议旨在能够在多播和尽力而为的传输方式（例如UDP/IP）上运行，并且只需要该传输方式提供非常简单的服务。实际上传输方式提供能够最大限度地发送数据包的无连接服务就足够了。也就是说传输方式不需要保证每个数据包会到达其目的地或者数据包按顺序传送。如果需要，RTPS在传输接口以上实现数据传输和状态的可靠性。这并不排除RTPS在可靠的传输方式之上实现。它使得支持更广泛的底层传输方式成为可能。

如果可以的话，RTPS还可以利用传输机制的多播功能，来自发送方的一条消息可以到达多个接收方。RTPS旨在促进底层通信机制的确定性。该协议提供了确定性和可靠性之间的公开权衡。
RTPS对底层传输方式的一般要求可归纳如下：

• 传输具有单播地址（长度应在16字节以内）的通用概念。
• 传输具有端口（长度应在4字节以内）的通用概念，例如可以是UDP端口或者共享存储器段中的偏移等。
• 传输可以将数据报（未解释的八位字节序列）发送到特定的地址/端口。
• 传输可以在特定地址/端口接收数据报。
• 如果传输过程中消息不完整或已损坏，传输将丢弃消息（即RTPS假定消息已完成且未损坏）。
• 传输提供推断接收消息大小的方法。

---

译文连载

RTPS规范-上一篇：实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_001

RTPS规范-下一篇：实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_003

DDS规范-译文连载：DDS (Data Distribution Service) 数据分发服务-规范中文翻译_001

---

相关链接

DDS科普：一文读懂DDS（数据分发服务）

DDS定义：什么是DDS？

产品介绍：BLUE DCS分布式数据连接解决方案

产品试用： 海蓝云平台-Blue DCS