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

需积分: 0 174 浏览量更新于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)

发布订阅协议v1.1（DDS）

RTP实时协议

美国地图json文件，可以使用arcgis转为spacefile

Microsoft Edge 126.0.2592.68 32位离线安装包

FLASH源码：读写FLASH内部数据，读取芯片ID

.Net 8.0 读写西门子plc和AB plc

小程序-家居装修团购小程序

C语言课程设计任务书 - 选课系统.docx

Государственный гимн СССР

面向对象：接口与多态 go 教程.md

Java项目-基于Springboot+Vue的大学生租房系统的设计与实现（源码+数据库脚本+部署视频+代码讲解视频+全套软件

“人力资源+大数据+薪酬报告+涨薪调薪”

31_Docker_安装mysql.avi

springboot数码论坛系统设计与实现（源码+lw+ppt+演示视频）.rar

基于matlab ChatGPT使用方法.m

测试嵌入式设备上网卡的脚本

sony 1.3寸VRoled屏幕

2024年东南亚4-甲基吗啉-N-氧化物市场深度研究及预测报告.pdf

2001-2022年 上市公司债务融资成本数据（原始数据、计算代码、参考文献和最终计算结果）.zip

会员权益专享

最新资源

2001-2022年上市公司债务融资成本数据（原始数据、计算代码、参考文献和最终计算结果）.zip