rtps协议——综述

7.1 说明
采用数据分发服务规范定义了应用级接口和数据分发服务的行为，支持实时的数据发布-订阅，DDS规范使用模型驱动架构（MDA）精确描述数据中心通信模型：

• 对应用程序的发送、接收建模
• 对应用程序与DCPS中间件交互发送、接收数据及服务质量的要求
• 如何进行数据收发
• 应用程序如何访问数据
• 应用程序从中间件的状态获取反馈类型
  DDS规范还包含一个特定于平台的IDL映射，DDS有线协议应该能够通过DDS的qos配置优化底层的传输功能，特别的，可以利用多播、best-effort、无连接等DDS qos的多种特性实现该有线协议的可用性。

7.2 DDS有线协议的要求
在网络通信中，“一刀切”并不适合所有领域。工程设计就是要做出正确的权衡，这些权衡必须平衡相互冲突的需求，例如通用性、易用性、功能丰富性、性能、内存大小和使用情况、可扩展性、确定性和稳健性。这些权衡必须根据信息流的类型（例如，周期性与突发性、基于状态与基于事件、一对多与请求-回复、尽力而为与可靠、小数据值与大文件等）以及应用程序和执行平台施加的约束来进行。
DDS 的基本通信模型是单向数据交换，其中发布数据的应用程序将相关数据“推送”到订阅者的本地缓存中。此信息流由 DataWriters 和 DataReaders 之间隐式建立的 QoS 契约进行调节。DataWriter 在声明发布数据的意图时指定其 QoS，而 DataReader 在声明订阅数据的意图时指定 QoS。通信模式通常包括多对多样式配置。部署 DDS 技术的应用程序主要关注的是，以最小的开销高效地分发信息。另一个重要要求是需要以强大的容错方式扩展到数百或数千个订阅者。
DDS 规范规定了内置发现服务的存在，该服务允许发布者动态发现订阅者的存在，而无需关联任何名称服务器。
DDS 规范还规定，实现不应引入任何单点故障。因此，协议不能依赖于集中式名称服务器或集中式信息代理。
部署 DDS 的应用程序具有大规模、松散耦合、动态的特性，需要适应新兴的传输方式，这要求数据定义和协议具有一定的灵活性，以便每个都可以发展，同时保持与已部署系统的向后兼容性。

7.3 RTPS有线协议
RTPS 是专门为支持数据分发系统的独特要求而开发的。无论是在底层架构还是rtps功能层面，DDS 和 RTPS 有线协议之间存在密切的协同作用。
RTPS 协议设计能够使用多播和无连接的best-effort传输（如 UDP/IP）。RTPS 协议的主要功能包括：

• 性能和服务质量属性，使实时应用程序能够通过标准 IP 网络实现best-effort和reliable的发布订阅通信。
• 容错性，允许创建没有单点故障的网络。
• 可扩展性，允许使用新服务扩展和增强协议，而不会破坏向后兼容性和互操作性。
• 即插即用连接，以便自动发现新应用程序和服务，并且应用程序可以随时加入和离开网络，而无需重新配置。
• 可配置性，允许平衡每次数据传输的可靠性和及时性要求。
• 模块化，允许简单设备实现协议的子集并仍参与网络。
• 可扩展性，使系统能够潜在地扩展到非常大的网络。
• 类型安全，以防止应用程序编程错误损害远程节点的操作。
  上述特性使 RTPS 成为 DDS 有线协议的完美匹配。此规范定义了使用 RTPS 协议的应用程序交换的所有消息所依据的消息格式、解释和使用场景。

7.4 RTPS平台独立模型（PIM）
RTPS协议根据PIM和一组PSM进行描述。RTPS PIM包含4个模块：Structure, Messages, Behavior, 和Discovery，Structure模块定义通信端点。Messages模块定义这些端点可以交换的消息集。Behavior模块定义合法交互（消息交换）集以及它们如何影响通信端点的状态，也就是说，Structure模块定义协议的“actors”，Messages模块定义一系列“语法符号”，Behavior模块定义不同对话的合法语法和语义，Discovery模块定义如何自动发现和配置实体。

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

7.4.1 Structure模块
此规范使用了许多与 DDS 规范中相同的核心实体。如图所示，所有 RTPS 实体都与 RTPS 域相关联，该域包含一组参与者的单独通信平面。参与者包含包含本地端点的组。有两种端点：Reader和Writer。Reader和Writer是通过发送 RTPS 消息来传达的。Writers通知存在情况并将域上的本地可用数据发送给可以请求和确认数据的Readers。

RTPS 协议中的参与者与DDS 实体一一对应。如图所示

7.4.2 Messages模块
Messages模块定义了 RTPS Writer和Reader之间原子信息交换的内容。消息由一个Header和随后的多个子消息组成，如图所示。每个子消息都由一系列子消息元素构建而成。选择此结构是为了允许子消息词汇表的扩展和组成每个子消息的扩展，同时保持向后兼容性。HeaderExtension 是一种特殊的子消息，可以选择紧跟在Header之后出现。

7.4.3 Behavior模块
Behavior模块描述了 RTPS Writer和Reader之间可以交换的消息的允许序列，以及每条消息引起的Writer和Reader状态的时间和变化。
为了说明这一概念，行为模块定义了两个参考实现。一个参考实现基于 StatefulWriters 和 StatefulReaders，另一个基于 StatelessWriters 和 StatelessReaders。

7.4.4 Discovery模块
Discovery模块描述了使参与者能够获取有关域中所有其他参与者和端点的存在和属性的信息的协议。此元流量使每个参与者能够获得域中所有Participant、Writer和Reader的完整信息，并配置本地Writer与远程Reader的通信，本地Reader与远程Writer的通信。

7.5 RTPS平台特定模型（PSM）
平台特定模型将 RTPS PIM 映射到特定的底层平台。它定义了所有 RTPS 类型和消息以及任何其他特定于平台的信息（以位和字节为单位）的精确表示。可以支持多个 PSM，但所有 DDS 实现都必须至少在 UDP/IP 之上实现 PSM

7.6 RTPS传输模块
RTPS 支持多种传输方式和传输 QoS。该协议能够实现多播和best-effort的传输（例如 UDP/IP），并且只需要传输层提供非常简单的服务。事实上，传输提供best-effort发送数据包的无连接服务就足够了。也就是说，传输不需要保证每个数据包都能到达目的地或数据包按顺序交付。如果需要，RTPS 会在传输接口上方实现数据传输和状态的可靠性。这并不妨碍在可靠的传输之上实现 RTPS。它只是使支持更广泛的传输成为可能。
如果可以，RTPS 还可以利用传输机制的多播功能，其中来自发送方的一条消息可以到达多个接收方。RTPS 旨在促进底层通信机制的确定性。该协议在确定性和可靠性之间提供了开放的权衡。
RTPS 对底层传输的一般要求可以总结如下：

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