RTPS（Real-Time Publish-Subscribe Wire Protocol）是DDS（Data Distribution Service）规范的核心组成部分和底层通信协议。它定义了DDS实体（如DataWriter和DataReader）之间如何在网络上实际交换信息，实现发布-订阅模型的互操作性和实时通信。
以下是关于 DDS 中 RTPS 协议的详细解释：
-
定位与目的
- 互操作性协议：RTPS 的核心目标是提供不同 DDS 实现（来自不同供应商）之间进行通信的标准方式。它定义了 DDS 实体（发布者、订阅者、数据写入器、数据读取器）如何在网络上交换发现信息和实际应用数据的线协议。
- 实时通信基础：它专为满足分布式实时系统的需求而设计，强调低延迟、可预测性、可靠性和可扩展性。
- 网络承载：RTPS 通常运行在 UDP/IP 之上（利用其多播能力进行高效发现），但也支持 TCP/IP 和其他传输层协议（用于点对点可靠通信或穿越防火墙）。它属于应用层协议。
-
关键特性和设计目标
- 互操作性：这是 RTPS 存在的首要原因。遵循 RTPS 标准的任何 DDS 实现都可以与其他遵循标准的实现进行通信。
- 实时性：协议设计考虑了实时约束，通过 QoS 策略（如截止期限、基于时间的过滤、流量控制）和高效的报文格式来支持可预测的端到端延迟。
- 可靠性：提供可配置的可靠性保证。支持“尽力而为 BEST_EFFORT”和“可靠 RELIABLE”两种模式。在可靠模式下，使用类似 TCP 的 ACK/NACK 机制（但更灵活、高效，支持多播）来确保数据按顺序、无丢失地传输。
- 可扩展性：利用 UDP 多播进行高效的发现（自动找到网络上的参与者、主题、端点），极大地减少了发现大量实体时的网络流量和配置负担。支持大规模分布式系统。
- 平台无关性：作为标准协议，它独立于操作系统、编程语言和硬件平台。
- 灵活性：支持多种拓扑结构（点对点、多播、广播）和通信模式（一对一、一对多、多对一、多对多）。
- 冗余与容错：支持发现和使用冗余的数据写入器（发布者端）和数据读取器（订阅者端），增强了系统的容错能力。
- 松耦合/匿名发布订阅：生产者和消费者在空间（位置透明）和时间（生命周期解耦）上解耦。发布者和订阅者无需直接知道对方的存在，通过主题进行匹配。
- 动态发现：RTPS 定义了强大的发现协议（SPDP - Simple Participant Discovery Protocol 和 SEDP - Simple Endpoint Discovery Protocol），使得 DDS DomainParticipant 能够自动发现彼此，并进一步发现域内的 DataWriter 和 DataReader 及其 QoS 设置和主题类型信息。这是实现“即插即用”的关键。
- 多播支持：原生支持多播，这是实现高效的一对多通信和发现的基础。
- 模块化传输：虽然通常与 UDP/IP（特别是多播）关联以实现最佳性能和实时性，但 RTPS 规范定义了传输抽象，理论上可以映射到不同的底层传输协议（如 TCP、共享内存、甚至自定义的背板总线）。实际实现中，UDP 是最常用和优化的。
-
核心概念与组件
- Domain：逻辑通信分区。只有属于同一个域的参与者才能互相发现和通信。RTPS 发现消息会携带域 ID。
- DomainParticipant：代表一个应用程序加入到一个域中。它是创建发布者、订阅者、主题等实体的工厂。RTPS 定义了
RTPSParticipant及其 GUID (Globally Unique Identifier)。 - Endpoint
- RTPSWriter：对应 DDS 的
DataWriter，负责将数据样本（Sample）发送到网络上。 - RTPSReader：对应 DDS 的
DataReader，负责从网络上接收数据样本。
- RTPSWriter：对应 DDS 的
- Locator：定义网络地址和端口（例如，IPv4 地址+端口号），用于标识通信端点。
- GUID：全局唯一标识符，用于在网络中唯一标识一个 RTPSParticipant、Writer 或 Reader。
- Topic：定义数据的名称和类型。RTPS 发现协议通过 Topic 名称和数据类型来匹配 Reader 和 Writer。
- Data Sample：应用数据的实例，包含实际的数据值以及序列号、时间戳等元数据。
- RTPS Message： 一个或多个子消息的集合，封装在一个传输层数据包（如 UDP Datagram）中发送。
- History Cache：Writer 和 Reader 端都维护一个历史缓存，用于存储已发送/接收的数据样本。这是实现可靠性（重传）和 QoS（如历史深度）的基础。
-
协议结构
RTPS 协议主要分为两大子协议：- 发现协议
- SPDP (Simple Participant Discovery Protocol)：用于发现同一个域中的
DomainParticipant。参与者周期性地（通过多播或单播）发送包含自身信息（GUID、QoS、单播定位器Locator等）的SPDPdiscoveredParticipantData消息。接收到此消息的参与者就知道对方的存在。 - SEDP (Simple Endpoint Discovery Protocol)：在参与者发现彼此之后，它们使用 SEDP 来交换各自域内创建的端点（Writer/Reader）的信息。每个参与者会发送描述其拥有的 Writer (
SEDPbuiltinPublicationsWriter) 和 Reader (SEDPbuiltinSubscriptionsWriter) 的消息（包含 Topic 名称、数据类型、QoS、GUID、端点定位器等）。其他参与者接收到这些消息后，就能知道哪些端点是可用的，并能根据 Topic 和类型进行匹配。匹配成功的端点对之间建立通信通道。SEDP 通常使用单播。
- SPDP (Simple Participant Discovery Protocol)：用于发现同一个域中的
- 消息交换协议
- 负责在匹配好的 Writer 和 Reader 之间传输实际的数据样本和控制信息。
- Writer -> Reader 消息
- Data：携带实际应用数据样本（序列化后的）和元数据（序列号、Writer GUID、时间戳等）。
- Heartbeat：周期性发送，告知 Reader 自己已发送的数据序列号范围（
firstSN,lastSN）。Reader 据此判断是否缺失数据。 - Gap：通知 Reader 某些序列号的数据被 Writer 主动跳过或丢弃了（例如由于历史缓存满或基于时间的过滤），Reader 可以跳过请求这些数据。
- Reader -> Writer 消息
- ACK/NACK：在可靠通信模式下：
- ACK：确认已成功接收到某个序列号之前的所有数据（累积确认）。
- NACK：通知 Writer 自己缺失了哪些序列号的数据（
bitmap或range表示），请求重传。
- Heartbeat Response：响应 Writer 的 Heartbeat 消息，告知自己当前接收到的序列号状态（
finalSN，可能包含位图指示缺失）。
- ACK/NACK：在可靠通信模式下：
- 发现协议
-
RTPS 消息格式
- 一个 RTPS 消息由一个 Header 后跟一个或多个 Submessages 组成。
- Header：包含协议标识 (
RTPS)、协议版本、供应商 ID (VendorId)、GUID 前缀 (GuidPrefix) 等。 - Submessage：是协议功能的基本单元。每个 Submessage 有自己的头部（Submessage ID、标志位、长度）和特定内容。常见的 Submessage ID 包括：
INFO_DST,INFO_SRC： 提供目标/源 GUID 前缀。DATA： 携带数据样本。HEARTBEAT： Writer 的心跳。ACKNACK： Reader 的 ACK/NACK。GAP： Writer 的 GAP 通知。INFO_TS： 提供时间戳。DATA_FRAG： 用于传输大于 MTU 的数据样本的分片。HEARTBEAT_FRAG： 分片数据的心跳。NACK_FRAG： 针对分片数据的 NACK。
-
工作流程简述
- 发现：
- 新加入的
RTPSParticipant通过多播发送 SPDP 消息宣告自己。 - 现有参与者收到后，建立单播连接并交换 SEDP 消息，宣告/发现彼此的 Writer 和 Reader 端点及其主题、类型、QoS。
- 匹配的 Writer 和 Reader 建立关联。
- 新加入的
- 数据交换：
- Writer 将应用数据封装在
DATA子消息中发送（多播或单播）。 - 可靠的 Reader 如果检测到丢包（通过序列号间隙），会发送
NACK子消息请求重传。 - Writer 收到
NACK后，重传丢失的数据 (DATA或DATA_FRAG)。 - Writer 定期发送
HEARTBEAT告知它拥有的数据序列范围。 - 当 Writer 知道某些旧数据永远不会再被发送（例如历史缓存被覆盖），会发送
GAP子消息通知 Reader。 - 可靠的 Reader 在收到数据后发送
ACK确认（可能累积确认）。
- Writer 将应用数据封装在
- QoS 实施：RTPS 协议消息承载了实现各种 DDS QoS 策略所需的信息和机制（如
HEARTBEAT频率影响延迟，可靠性机制，基于时间的过滤等）。
- 发现：
-
与 DDS 的关系
- DDS 是一个 API 标准 (OMG DDS Specification)，定义了应用程序如何与数据分发服务交互（创建主题、读写数据、设置 QoS 等）。
- RTPS 是 DDS 的 底层通信协议标准 (OMG RTPS Specification)。它规定了 DDS 实体之间如何通过网络进行发现和数据交换，以实现 DDS API 的语义和 QoS。
- DDS 实现 = DDS API 实现 + RTPS 协议栈实现。 一个符合标准的 DDS 中间件产品必须实现 RTPS 协议才能与其他符合标准的 DDS 实现互操作。
- DDS 的 QoS 策略（如可靠性、持久性、截止期限、历史记录等）最终都需要映射到 RTPS 协议的行为和消息交换上。
-
应用场景
RTPS 作为 DDS 的基石，被广泛应用于需要高性能、可靠、实时、可扩展通信的领域：- 工业自动化与控制系统 (IACS)
- 航空航天与国防 (航电系统、任务系统)
- 自动驾驶与智能交通系统
- 医疗设备
- 金融交易系统
- 能源与电网管理
- 分布式仿真
总结
RTPS 是 DDS 生态系统中的核心通信协议和互操作性支柱。它解决了分布式实时系统中关键的服务发现和高效、可靠、可扩展的数据传输问题。通过定义标准化的线协议、发现机制（SPDP/SEDP）和消息交换机制（Data, Heartbeat, AckNack, Gap），RTPS 确保了不同 DDS 实现之间可以无缝协作，并支撑了 DDS API 所承诺的各种服务质量（QoS）。理解 RTPS 的工作原理对于设计、部署和调试基于 DDS 的系统至关重要。
扫一扫
502
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
