"DDS-RTPS实时发布订阅协议版本2.3详解与规范解读"

需积分: 0 76 浏览量更新于2024-01-11 1 收藏 7.44MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

DDS-RTPS实时发布订阅协议是一种面向分布式系统的通信协议，用于实现实时数据的发布和订阅。它采用了RTPS（Real-time Publish-Subscribe）协议作为其互操作的传输协议规范。DDS-RTPS协议旨在提供一种可扩展、可靠和实时的通信机制，允许分布式系统的各个组件之间以异步的方式进行实时数据传输。 DDS-RTPS协议的最新版本是DDSI-RTPS version 2.3，发布于2018年9月。该版本是OMG（Object Management Group）的标准文档，其规范细节可以在OMG的官方网站上找到。协议的版权归OMG、Real-time Innovations, Inc.和THALES所有。 DDS-RTPS协议提供了一种基于发布和订阅模型的通信机制。通过该协议，数据生产者可以将实时数据发布到一个或多个特定的话题（Topic），而数据消费者则可以通过订阅这些话题来接收和处理这些实时数据。DDS-RTPS协议使用一种分布式的触发机制，当数据发布者有新数据产生时，会通知所有订阅该话题的数据消费者。这种机制可以确保数据的实时性和可靠性。 DDS-RTPS协议支持复杂的数据类型和灵活的消息传输方式。它定义了一种数据类型描述语言（Type Definition Language），允许开发人员定义自定义的数据类型。这些数据类型可以包含基本数据类型、结构体、枚举等，以满足不同应用场景的需求。在消息的传输方面，DDS-RTPS协议提供了多种传输方式，包括UDP、TCP/IP和共享内存等，以适应不同网络环境和性能要求。 DDS-RTPS协议还支持多种QoS（Quality of Service）策略，以满足不同应用场景的实时性和可靠性需求。通过QoS策略，开发人员可以定义数据传输的延迟、带宽、可靠性和安全性等参数。这些参数可以在运行时进行调整，以适应网络环境的变化和系统的性能需求。除了核心的发布订阅功能外，DDS-RTPS协议还提供了一些附加功能，以方便开发人员进行系统的监测和管理。例如，协议支持系统状态的监测和统计信息的收集，以帮助开发人员进行性能调优和故障排查。此外，协议还提供了一种分布式文件存储机制，允许数据的历史记录和回放。总之，DDS-RTPS实时发布订阅协议是一种强大的通信协议，用于实现分布式系统中实时数据的发布和订阅。它提供了可靠、实时和可扩展的通信机制，适用于各种应用场景。协议还支持多种QoS策略和附加功能，以提供更灵活和可管理的系统。随着技术的不断进步，DDS-RTPS协议将继续发展，为实时通信领域带来更多的创新和进步。

资源详情

资源推荐

16 DDSI-RTPS version 2.3

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 17

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.

DDSI-RTPS version 2.3 19

Writer

Specialization of RTPS Endpoint representing the objects that can be the sources of

messages communicating CacheChanges.

Reader

Specialization of RTPS Endpoint representing the objects that can be used to receive

messages communicating CacheChanges.

HistoryCache

Container class used to temporarily store and manage sets of changes to data-objects.

On the Writer side it contains the history of the changes to data-objects made by the

Writer. It is not necessary that the full history of all changes ever made is maintained.

Rather what is needed is the partial history required to service existing and future

matched RTPS Reader endpoints. The partial history needed depends on the DDS QoS

and the state of the communications with the matched Reader endpoints.

On the Reader side it contains the history of the changes to data-objects made by the

matched RTPS Writer endpoints. It is not necessary that the full history of all changes

ever received is maintained. Rather what is needed is a partial history containing the

superposition of the changes received from the matched writers as needed to satisfy the

needs of the corresponding DDS DataReader. The rules for this superposition and the

amount of partial history required depend on the DDS QoS and the state of the

communication with the matched RTPS Writer endpoints.

CacheChange

Represents an individual change made to a data-object. Includes the creation,

modification, and deletion of data-objects.

Data

Represents the data that may be associated with a change made to a data-object.

8.2.1.2 Summary of the types used to describe RTPS Entities and Classes

The Entities and Classes used by the virtual machine each contain a set of attributes. The types of the attributes are

summarized in Table 8.2.

Table 8.2 - Types of the attributes that appear in the RTPS Entities and Classes

Types used within the RTPS Entities and Classes

Attribute type

Purpose

GUID_t

Type used to hold globally-unique RTPS-entity identifiers. These are identifiers used

to uniquely refer to each RTPS Entity in the system.

Must be possible to represent using 16 octets.

The following values are reserved by the protocol: GUID_UNKNOWN

GuidPrefix_t

Type used to hold the prefix of the globally-unique RTPS-entity identifiers. The

GUIDs of entities belonging to the same participant all have the same prefix (see

8.2.4.3).

Must be possible to represent using 12 octets.

The following values are reserved by the protocol: GUIDPREFIX_UNKNOWN

EntityId_t

Type used to hold the suffix part of the globally-unique RTPS-entity identifiers. The

EntityId_t uniquely identifies an Entity within a Participant.

Must be possible to represent using 4 octets.

The following values are reserved by the protocol: ENTITYID_UNKNOWN

Additional pre-defined values are defined by the Discovery module in 8.5.

SequenceNumber_t

Type used to hold sequence numbers.

Must be possible to represent using 64 bits.

The following values are reserved by the protocol:

SEQUENCENUMBER_UNKNOWN

20 DDSI-RTPS version 2.3

Locator_t

Type used to represent the addressing information needed to send a message to an

RTPS Endpoint using one of the supported transports.

Should be able to hold a discriminator identifying the kind of transport, an address,

and a port number. It must be possible to represent the discriminator and port

number using 4 octets each, the address using 16 octets.

The following values are reserved by the protocol:

LOCATOR_INVALID

LOCATOR_KIND_INVALID

LOCATOR_KIND_RESERVED

LOCATOR_KIND_UDPv4

LOCATOR_KIND_UDPv6

LOCATOR_ADDRESS_INVALID

LOCATOR_PORT_INVALID

TopicKind_t

Enumeration used to distinguish whether a Topic has defined some fields within to

be used as the ‘key’ that identifies data-instances within the Topic. See the DDS

specification for more details on keys.

The following values are reserved by the protocol:

NO_KEY

WITH_KEY

ChangeKind_t

Enumeration used to distinguish the kind of change that was made to a data-object.

Includes changes to the data or the instance state of the data-object.

It can take the values:

ALIVE, ALIVE_FILTERED, NOT_ALIVE_DISPOSED,

NOT_ALIVE_UNREGISTERED

ReliabilityKind_t

Enumeration used to indicate the level of the reliability used for communications.

It can take the values:

BEST_EFFORT, RELIABLE.

InstanceHandle_t

Type used to represent the identity of a data-object whose changes in value are

communicated by the RTPS protocol.

ProtocolVersion_t

Type used to represent the version of the RTPS protocol. The version is composed

of a major and a minor version number. See also 8.6.

The following values are reserved by the protocol:

PROTOCOLVERSION

PROTOCOLVERSION_1_0

PROTOCOLVERSION_1_1

PROTOCOLVERSION_2_0

PROTOCOLVERSION_2_1

PROTOCOLVERSION_2_2

PROTOCOLVERSION is an alias for the most recent version, in this case

PROTOCOLVERSION_2_2

VendorId_t

Type used to represent the vendor of the service implementing the RTPS protocol.

The possible values for the vendorId are assigned by the OMG.

The following values are reserved by the protocol:

VENDORID_UNKNOWN

8.2.1.3 Configuration attributes of the RTPS Entities

RTPS entities are configured by a set of attributes. Some of these attributes map to the QoS policies set on the

corresponding DDS entities. Other attributes represent parameters that allow tuning the behavior of the protocol to

specific transport and deployment situations. Additional attributes encode the state of the RTPS Entity and are not used to

configure the behavior.

The attributes used to configure a subset of the RTPS Entities are shown in Figure 8.2. The attributes to configure Writer

剩余184页未读，继续阅读

CCTVtz

粉丝: 0
资源: 2

会员权益专享

"DDS-RTPS实时发布订阅协议版本2.3详解与规范解读"

DDS-RTPS 实时发布订阅协议 DDS互操作协议规范(Version 2.1)

用于嵌入式设备的 RTPS/DDS 协议的可移植实现_C++_代码_相关文件_下载

RTPS formal-14-09-01.pdf

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

能详细介绍一下DDS－XRCE么

DDS相关的标准有哪些，分别是什么作用？

dds数据分发服务和rtps协议之间的关系

OpenDDS实现RTPS的C++例子

opendds的rtps传输模式详解，怎么避免rtps传输的内存增长

DDS－XTypes是什么

RTI协议和DDS协议最新版本

DDS automotive

opendds如何配置分布式发布订阅

free RTPS

RTI协议和DDS协议

ros2 humble 使用fast-dds在同一台物理机上发布订阅，如何配置使其使用tcp进行数据传输

1>d:\opendds\build\opendds\opendds-3.12\ace_wrappers\ace\process.h(145): error C2059: 语法错误:“)” 1>d:\opendds\build\opendds\opendds-3.12\ace_wrappers\ace\process.h(149): error C2143: 语法错误: 缺少“)”(在“;”的前面)

xrce-dds标准协议的中文版

通过Wrieshark 抓包可以获取fast-dds发布的topic信息吗？如何查看具体信息

会员权益专享

最新资源