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

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

RTPS (Real-time Publish-Subscribe Protocol Specification) 是由 Object Management Group (OMG) 制定的一个关键的实时通信协议，其版本为2.2，最初发布于2014年9月1日。这份文档专注于实现 DDS (Data Distribution Service for Real-Time Systems) 中间件之间的互操作性。DDS是一种专为实时和嵌入式系统设计的消息传递框架，它支持发布/订阅模式，使得数据生产者可以向多个订阅者广播消息，而无需维护直接连接。 RTPS协议是DDS基础设施中的核心组件，它定义了数据的传输、确认、错误处理和安全等方面的标准。它包括以下几个主要部分： 1. **数据传输**：RTPS提供了高效的、无损的数据传输，确保数据在分布式系统中的可靠传输。它支持多种传输模式，如单播、组播和广播，满足不同应用场景的需求。 2. **服务质量(QoS)**：RTPS允许设置和管理QoS参数，如数据速率、可靠性、延迟等，以保证数据的实时性和一致性。这对于保证分布式系统中各个节点间的同步至关重要。 3. **发现与连接**：协议包含了一套完整的发现服务机制，使得参与者能够动态地找到其他参与者的地址，并建立连接，增强了系统的动态性和灵活性。 4. **安全性**：RTPS支持安全措施，如加密和身份验证，保护数据在传输过程中的隐私和完整性。 5. **标准化与兼容性**：OMG制定的规范旨在促进不同供应商之间的互操作性，确保不同厂商的DDS实现能够无缝集成。文档中提到的Machine Consumable Files提供了更多的技术细节和实现指南。 6. **许可与使用**：文档中的版权信息表明，Real-time Innovations Inc. 和 Thales等公司已经授予OMG非独家、免版税的世界范围内的权利，允许复制、分发和修改此规范，并且这些权利可能会随着时间和需求的变化而更新。总结来说，RTPS formal-14-09-01.pdf文档是一个重要的技术文档，对于理解和设计基于RTPS的实时分布式系统，理解其协议架构、特性及其实现细节是至关重要的。它为开发人员和系统架构师提供了设计高效、可靠的DDS应用程序的基础，特别是在那些对实时性和数据一致性有高要求的领域，如自动驾驶、航空航天和工业自动化等。

4 DDS Interoperability Protocol, v2.2

DDS Interoperability Protocol, v2.2 5

7Overview

7.1 Introduction

The recently-adopted Data-Distribution Service specification defines an Application Level Interface and behavior of a

Data-Distribution Service (DDS) that supports Data-Centric Publish-Subscribe (DCPS) in real-time systems. The DDS

specification used a Model-Driven Architecture (MDA) approach to precisely describe the Data-Centric communications

model specifically:

• how the application models the data it wishes to send and receive,

• how the application interacts with the DCPS middleware and specifies the data it wishes to send and receive as well as

the quality of service (QoS) requirements,

• how data is sent and received (relative to the QoS requirements),

• how the applications access the data, and

• the kinds of feedback the application gets from the state of the middleware.

The DDS specification also includes a platform specific mapping to IDL and therefore an application using DDS is able

to switch among DDS implementations with only a re-compile. DDS therefore addresses ‘application portability.’

The DDS specification does not address the protocol used by the implementation to exchange messages over transports

such as TCP/UDP/IP, so different implementations of DDS will not interoperate with each other unless vendor-specific

“bridges” are provided. The situation is therefore similar to that of other messaging API standards such as JMS.

With the increasing adoption of DDS in large distributed systems, it is desirable to define a standard “wire protocol” that

allows DDS implementations from multiple vendors to interoperate. The desired “DDS wire protocol” should be capable

of taking advantage of the QoS settings configurable by DDS to optimize its use of the underlying transport capabilities.

In particular, the desired wire protocol must be capable of exploiting the multicast, best-effort, and connectionless nature

of many of the DDS QoS settings.

7.2 Requirements for a DDS Wire-protocol

In network communications, as in many other fields of engineering, it is a fact that “one size does not fit all.” Engineering

design is about making the right set of trade-offs, and these trade-offs must balance conflicting requirements such as

generality, ease of use, richness of features, performance, memory size and usage, scalability, determinism, and

robustness. These trade-offs must be made in light of the types of information flow (e.g., periodic vs. bursty, state-based

vs. event-based, one-to-many vs. request-reply, best-effort vs. reliable, small data-values vs. large files, etc.), and the

constraints imposed by the application and execution platforms. Consequently, many successful protocols have emerged

such as HTTP, SOAP, FTP, DHCP, DCE, RTP, DCOM, and CORBA. Each of these protocols fills a niche, providing well-

tuned functionality for specific purposes or application domains.

The basic communication model of DDS is one of unidirectional data exchange where the applications that publish data

“push” the relevant data updates to the local caches of co-located subscribers to the data. This information flow is

regulated by QoS contracts implicitly established between the DataWriters and the DataReaders. The DataWriter specifies

its QoS contract at the time it declares its intent to publish data and the DataReader does it at the time it declares its intent

to subscribe to data. The communication patterns typically include many-to-many style configurations. Of primary

6 DDS Interoperability Protocol, v2.2

concern to applications deploying DDS technology is that the information is distributed in an efficient manner with

minimal overhead. Another important requirement is the need to scale to hundreds or thousands of subscribers in a robust

fault-tolerant manner.

The DDS specification prescribes the presence of a built-in discovery service that allows publishers to dynamically

discover the existence of subscribers and vice-versa and performs this task continuously without the need to contact any

name servers.

The DDS specification also prescribes that the implementations should not introduce any single points of failure.

Consequently protocols must not rely on centralized name servers or centralized information brokers.

The large scale, loosely-coupled, dynamic nature of applications deploying DDS and the need to adapt to emerging

transports require certain flexibility on the data-definition and protocol such that each can be evolved while preserving

backwards compatibility with already deployed systems.

7.3 The RTPS Wire-protocol

The Real-Time Publish Subscribe (RTPS) protocol found its roots in industrial automation and was in fact approved by

the IEC as part of the Real-Time Industrial Ethernet Suite IEC-PAS-62030. It is a field proven technology that is currently

deployed worldwide in thousands of industrial devices.

RTPS was specifically developed to support the unique requirements of data-distributions systems. As one of the

application domains targeted by DDS, the industrial automation community defined requirements for a standard publish-

subscribe wire-protocol that closely match those of DDS. As a direct result, a close synergy exists between DDS and the

RTPS wire-protocol, both in terms of the underlying behavioral architecture and the features of RTPS.

The RTPS protocol is designed to be able to run over multicast and connectionless best-effort transports such as UDP/IP.

The main features of the RTPS protocol include:

• Performance and quality-of-service properties to enable best-effort and reliable publish-subscribe communications for

real-time applications over standard IP networks.

• Fault tolerance to allow the creation of networks without single points of failure.

• Extensibility to allow the protocol to be extended and enhanced with new services without breaking backwards

compatibility and interoperability.

• Plug-and-play connectivity so that new applications and services are automatically discovered and applications can join

and leave the network at any time without the need for reconfiguration.

• Configurability to allow balancing the requirements for reliability and timeliness for each data delivery.

• Modularity to allow simple devices to implement a subset of the protocol and still participate in the network.

• Scalability to enable systems to potentially scale to very large networks.

• Type-safety to prevent application programming errors from compromising the operation of remote nodes.

The above features make RTPS an excellent match for a DDS wire-protocol. Given its publish-subscribe roots, this is not

a coincidence, as RTPS was specifically designed for meeting the types of requirements set forth by the DDS application

domain.

This specification defines the message formats, interpretation, and usage scenarios that underlie all messages exchanged

by applications that use the RTPS protocol.

剩余209页未读，继续阅读

qk0923

粉丝: 18
资源: 7

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

[rtps]formal-19-04-03-rtps1.pdf

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

fast-rtps 1.5.0 patched for aarch64

解析fast-rtps数据获取头部各字段以及topicname的示例

ubuntu px4 安装

在ubuntu 18.04安装 colcon

wireshark rtps内容分析

wireshark解析RTPS报文

catkin_make -DCMAKE_BUILD_TYPE=Release 在ros2的指令

RTPS和rpc的异同点

最新资源