DDS-RTPS协议详解：官方文档重点解析

需积分: 21 129 浏览量更新于2024-07-16 收藏 10.66MB PDF 举报

"DDS-RTPS官方文档，版本2.3，是OMG（对象管理组织）发布的实时发布订阅协议（Real-time Publish-Subscribe Protocol，简称RTPS）的互操作性线缆协议规范。该文档详述了DDS-RTPS的工作流程、UML类图和状态图，对理解RTPS和DDS的交互机制有极大帮助。" DDS-RTPS（Real-Time Publish-Subscribe Protocol）是DDS（Data Distribution Service）的一个关键组成部分，它定义了数据在分布式系统中的传输方式，特别是针对实时和高可靠性需求的应用。DDS-RTPS是实现DDS跨厂商互操作性的标准通信协议。文档中的"Version 2.3"指的是DDS-I RTPS的第三个主要更新版本，这表明了该协议在不断演进以适应新的技术和需求。OMG文档编号"formal/2019-04-03"表明这是2019年4月3日正式发布的版本，可以在OMG的官方网站上找到。 RTPS的核心概念是发布者（Publisher）和订阅者（Subscriber），它们分别负责数据的生产和消费。发布者将数据写入网络，而订阅者则接收并处理这些数据。RTPS协议规定了这些实体如何发现彼此，建立连接，以及如何高效、可靠地传输数据。 DDS-I RTPS规范详细描述了数据包的结构、传输机制、错误处理和网络层的优化策略。其中，UML类图展示了协议中的各种实体及其关系，如数据读写器、数据流网络、传输配置等。状态图则揭示了协议实体在不同条件下的行为模式，例如从连接建立到断开的完整生命周期。标签中的"AUTOSAR"表明DDS-RTPS也被广泛应用在汽车软件领域的AUTOSAR（AUTomotive Open System ARchitecture）标准中，提供车辆电子系统的数据交换。总体来说，这份文档对于开发者、系统架构师和研究人员来说是深入理解DDS-RTPS和DDS的关键参考资料，它提供了实现和优化实时数据交换的详细指南。通过学习这份文档，读者能够掌握如何设计和实施满足严格性能要求的分布式系统。

DDSI-RTPS version 2.3

Figure 7.3 - Correspondence between RTPS and DDS Entries

The Structure module is described in 8.2.

7.4.2 The Messages Module

The messages module defines the content of the atomic information exchanges between RTPS Writers and

Readers. Messages are composed of a header followed by a number of Submessages, as illustrated in Figure 7.4.

Each Submessage is built from a series of Submessage elements. This structure is chosen to allow the

vocabulary of Submessages and the composition of each Submessage to be extended while maintaining

backward compatibility.

Figure 7.4 - RTPS Messages Module

The Messages module is discussed at length in 8.3.

7.4.3 The Behavior Module

The Behavior module describes the allowed sequences of messages that can be exchanged between RTPS

Writers and Readers as well as the timings and changes in the state of the Writer and the Reader caused by each

message.

The required behavior for interoperability is described in terms of a minimum set of rules that an

implementation must follow in order to be interoperable. Actual implementations may exhibit different behavior

beyond these minimum requirements, depending on how they wish to trade-off scalability, memory

requirements, and bandwidth usage.

To illustrate this concept, the Behavior module defines two reference implementations. One reference

implementation is based on StatefulWriters and StatefulReaders, the other on StatelessWriters and

StatelessReaders, as illustrated in Figure 7.2 - RTPS Structure Module. Both reference implementations

satisfy the minimum requirements for interoperability, and are therefore interoperable, but exhibit slightly

different behavior due to the difference in information they store on matching remote entities. The behavior of

an actual implementation of the RTPS protocol may be an exact match or a combination of that of the reference

implementations.

Topic

DDSI-RTPS version 2.3 17

The Behavior module is described in 8.4.

7.4.4 The Discovery Module

The Discovery module describes the protocol that enables Participants to obtain information about the

existence and attributes of all the other Participants and Endpoints in the Domain. This metatraffic enables

every Participant to obtain a complete picture of all Participants, Readers and Writers in the Domain and

configure the local Writers to communicate with the remote Readers and the local Readers to communicate

with the remote Writers.

Discovery is a separate module. The unique needs of Discovery, namely the transparent plug-and-play

dissemination of all the information needed to associate matching Writers and Readers make it unlikely that a

single architecture or protocol can fulfill the extremely variable scalability, performance, and embeddability

needs of the various heterogeneous networks where DDS will be deployed. Henceforth, it makes sense to

introduce several discovery mechanisms ranging from the simple and efficient (but not very scalable), to a

more complex hierarchical (but more scalable) mechanism.

The Discovery module is described in 8.5.

7.5 The RTPS Platform Specific Model (PSM)

A Platform Specific Model maps the RTPS PIM to a specific underlying platform. It defines the precise

representation in bits and bytes of all RTPS Types and Messages and any other information specific to the

platform.

Multiple PSMs may be supported, but all implementations of DDS must at least implement the PSM on top of

UDP/IP, which is presented in Clause 9.

7.6 The RTPS Transport Model

RTPS supports a wide variety of transports and transport QoS. The protocol is designed to be able to run on

multicast and best-effort transports, such as UDP/IP and requires only very simple services from the transport.

In fact, it is sufficient that the transport offers a connectionless service capable of sending packets best-effort.

That is, the transport need not guarantee each packet will reach its destination or that packets are delivered in-

order. Where required, RTPS implements reliability in the transfer of data and state above the transport

interface. This does not preclude RTPS from being implemented on top of a reliable transport. It simply

makes it possible to support a wider range of transports.

If available, RTPS can also take advantage of the multicast capabilities of the transport mechanism, where one

message from a sender can reach multiple receivers. RTPS is designed to promote determinism of the

underlying communication mechanism. The protocol provides an open trade-off between determinism and

reliability.

The general requirements RTPS poses on the underlying transport can be summarized as follows:

•

The transport has a generalized notion of a unicast address (shall fit within 16 bytes).

•

The transport has a generalized notion of a port (shall fit within 4 bytes), e.g., could be a UDP port,

an offset in a shared memory segment, etc.

•

The transport can send a datagram (uninterpreted sequence of octets) to a specific address/port.

•

The transport can receive a datagram at a specific address/port.

•

The transport will drop m essages if incomplete or corrupted during transfer (i.e., RTPS assumes

messages are complete and not corrupted).

•

The transport provides a means to deduce the size of the received message.

DDSI-RTPS version 2.3 19

8 Platform Independent Model (PIM)

8.1 Introduction

This clause defines the Platform Independent Model (PIM) for the RTPS protocol. Subsequent clauses map the

PIM to a variety of platforms, the most fundamental one being native UDP packets.

The PIM describes the protocol in terms of a “virtual machine.” The structure of the virtual machine is built

from the classes described in 8.2, which include Writer and Reader endpoints. These endpoints communicate

using the messages described in 8.3. Sub clause 8.4 describes the behavior of the virtual machine, i.e., what

message exchanges take place between the endpoints. It lists the requirements for interoperability and defines

two reference implementations using state- diagrams. Sub clause 8.5 defines the discovery protocol used to

configure the virtual machine with the information it needs to communicate with its remote peers. Sub clause

8.6 describes how the protocol can be extended for future needs. Finally, 8.7 describes how to implement DDS

QoS and some advanced DDS features using RTPS.

The only purpose of introducing the RTPS virtual machine is to describe the protocol in a complete and un-

ambiguous manner. This description is not intended to constrain the internal implementation in any way. The

only criteria for a compliant implementation is that the externally-observable behavior satisfies the requirements

for interoperability. In particular, an implementation could be based on other classes and could use

programming constructs other than state- machines to implement the RTPS protocol.

8.2 Structure Module

This sub clause describes the structure of the RTPS entities that are the communication actors. The main classes

used by the RTPS protocol are shown in Figure 8.1.

8.2.1 Overview

RTPS entities are the protocol-level endpoints used by the application-visible DDS entities in order to

communicate with each other.

Each RTPS Entity is in a one-to-one correspondence with a DDS Entity. The HistoryCache forms the interface

between the DDS Entities and their corresponding RTPS Entities. For example, each write operation on a DDS

DataWriter adds a CacheChange to the HistoryCache of its corresponding RTPS Writer. The RTPS Writer

subsequently transfers the CacheChange to the HistoryCache of all matching RTPS Readers. On the receiving

side, the DDS DataReader is notified by the RTPS Reader that a new CacheChange has arrived in the

HistoryCache, at which point the DDS DataReader may choose to access it using the DDS read or take API.

剩余188页未读，继续阅读

sxwen1234

粉丝: 0
资源: 2

DDS-RTPS协议详解：官方文档重点解析

RTPS 2.2官方规范：2014年发布订阅协议详解

在线申请RTPS Bihar收入和居住证服务

Fast-RTPS 1.5.0在aarch64架构下的补丁版本发布

RTPS formal-14-09-01.pdf

RTPS规范-v2.2-中文版-pfu.pdf

RTPS - Apply Online & Status For RTPS Bihar-crx插件

eprosima-fast-rtps.rar

RTPS协议的抓包实战：分析与技巧_rtps报文解析-CSDN博客.mhtml

Fast RTPS - User Manual

FastRtps.zip

最新资源