关键字:OMG,RTPS,DDS
The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification,Version 2.2,September 2014
8.3. 消息模块
消息模块描述了在RTPS Writer端点和RTPS Reader端点之间交换的消息的总体结构和逻辑内容。RTPS消息是模块化设计,可以轻松扩展以支持标准协议功能添加以及供应商专属内容的扩展。
8.3.1. 概述
消息模块章节的组织结构如下:
- 2.3.2介绍了后续子章节中定义RTPS消息所需的所有其他类型。
- 2.3.3描述了适用于所有RTPS消息的通用结构。所有RTPS消息都包含一个报文头(Header)以及一系列子消息(Submessages)。可以在单个RTPS消息中发送的子消息的数量受底层传输方式支持的最大消息大小的限制。
- 某些子消息可能会影响同一RTPS消息中后续子消息的解析。解析Submessages的上下文由RTPS消息接收器维护,并在2.3.4中描述。
- 2.3.5列出了用于创建子消息(Submessages)的基础构建块,也称为子消息元素(SubmessageElements),其中包括序列号集,时间戳,标识符等。
- 2.3.6描述了RTPS报文头的结构。固定大小的RTPS报文头用于标识RTPS消息。
- 2.3.7详细介绍了所有可用的子消息(Submessages)。对于每个Submessage,规范定义其内容、何时被认为是有效的以及它如何影响RTPS消息接收器的状态。PSM将在3.4.5中定义每个Submessage到线路传输上的位和字节的实际映射。
8.3.2. 类型定义
除了2.2.1.2中定义的类型之外,消息模块还使用表8-13中列出的类型。
表 8-13 用于定义RTPS消息的类型表
8.3.3. RTPS消息的总体结构
RTPS消息的整体结构包括固定大小的前导RTPS报文头(Header),后跟数量不定的RTPS子消息(Submessage)部分。每个子消息(Submessage)依次由子消息报文头(SubmessageHeader)和数量不定的子消息元素(SubmessageElements)组成。 如图8.8所示。
图 8-8 RTPS消息结构
RTPS协议发送的每条消息都有一个有限的长度。该长度不是由RTPS协议显式发送的,而是发送RTPS消息的底层传输方式的一部分。在面向分组的传输方式(如UDP/IP)情况下,消息的长度已由传输方式封装提供。面向流的传输方式(如TCP)需要在消息之前插入长度,以便识别RTPS消息的边界。
8.3.3.1. RTPS报文头(Header)结构
RTPS报文头(Header)必须出现在每条消息的开头。
图 8-9 RTPS消息报文头结构
报文头(Header)将消息标识为属于RTPS协议。报文头(Header)标识协议的版本和发送消息的供应商。报文头(Header)包含表2.14中列出的字段。
表 8-14 RTPS消息报文头(Header)结构
8.3.3.1.1. 协议(protocol)
协议(protocol)字段将消息标识为RTPS消息。该值设置为PROTOCOL_RTPS。
8.3.3.1.2. 版本(version)
版本(version)字段标识RTPS协议的版本。本文档之后的实现定义协议版本为2.2(major = 2,minor = 2),并将此字段设置为PROTOCOLVERSION。
8.3.3.1.3. 供应商ID(vendorId)
供应商ID(vendorId)标识了实现RTPS协议的中间件供应商ID,并允许该供应商添加协议的特定扩展。vendorId不是指包含RTPS中间件的设备或产品的供应商ID。vendorId由OMG分配。
该协议保留以下值:
VENDORID_UNKNOWN
供应商ID只能由承诺遵守当前主要协议版本的实现者持有。为了促进增量进化,供应商ID列表与此规范分开管理。该列表在OMG DDS Wiki中维护,可从以下网址访问:http://www.omgwiki.org/dds/content/page/dds-rtps-vendor-and product-ids。
新供应商ID的请求应通过电子邮件发送至dds@omg.org。
8.3.3.1.4. GUID前缀(guidPrefix)
GUID前缀(guidPrefix)定义了一个默认前缀,可用于重建消息中包含的子消息(Submessages)中出现的全局唯一标识符(GUID)。guidPrefix允许子消息(Submessages)只包含GUID的EntityId部分,因此不必在每个GUID上重复出现公共前缀(见8.2.4.1)。