实时发布订阅协议（RTPS）DDS互操作网络协议规范-中文翻译_008

最新推荐文章于 2025-03-13 15:07:49 发布

DDS数据分发服务

最新推荐文章于 2025-03-13 15:07:49 发布

阅读量3.9k

点赞数 2

分类专栏： RTPS规范

RTPS规范专栏收录该内容

10 篇文章

订阅专栏

本文详细介绍了RTPS（实时发布订阅协议）中子消息的结构，包括子消息ID、标志和长度字段，强调了子消息在RTPS消息中的重要性，并阐述了RTPS消息接收器的规则，旨在促进DDS（数据分发服务）的互操作性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

关键字：OMG，RTPS，DDS

The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification，Version 2.2，September 2014

8.3.3.2. 子消息（Submessage）结构

每个RTPS消息由可变数量的RTPS子消息（Submessage）部分组成。所有RTPS子消息都具有相同的结构，如图8-10所示。

在这里插入图片描述

图 8-10 RTPS子消息（Submessage）结构

所有Submessages都以SubmessageHeader部分开头，后跟SubmessageElement部分的串联。

SubmessageHeader标识Submessage的种类以及Submessage中的可选元素。 SubmessageHeader包含表8-15中列出的字段。

表 8-15 子消息报文头（SubmessageHeader）结构
在这里插入图片描述
在协议的主要版本（2）中不能更改RTPS子消息（Submessage）的结构。

8.3.3.2.1. 子消息ID（submessageId）

子消息ID（submessageId）标识子消息（Submessage）的种类。有效ID由SubmessageKind的可能值枚举定义（参见表8-13）。

在此主要版本（2）中无法修改子消息ID的含义。可以在较高的次要版本中添加其他子消息类型。为了保持与未来版本的互操作，平台特定映射应保留一系列用于协议扩展的值以及为特定于供应商的子消息保留的值，这些值将永远不会被未来版本的RTPS协议使用。

8.3.3.2.2. 标志（flags）

Submessage报文头中的标志（flags）包含8个布尔值。第一个标志EndiannessFlag并位于所有子消息的相同位置，表示对Submessage中的信息进行编码的字节序。文字“E”通常用于表示EndiannessFlag。

如果EndiannessFlag设置为FALSE，则Submessage以大端格式编码，EndiannessFlag设置为TRUE表示小端编码。

其他标志的解释取决于Submessage的类型。

8.3.3.2.3. 子消息长度（submessageLength）

本字段代表子消息（Submessage）的长度（不包括Submessage报文头Header）。

如果submessageLength> 0，则它是

从Submessage内容开始到下一个Submessage报文头（Header）开始的长度（如果Submessage不是消息中的最后一个Submessage）。
或者是剩余的消息长度（如果Submessage是消息中的最后一个Submessage）。 Message的解释器可以区分这两种情况，因为它知道Message的总长度。

如果submessageLength == 0，则Submessage是Message中的最后一个Submessage，并一直延伸到Message的末尾。这使得可以发送大于64KB（可以存储在submessageLength字段中的最大长度）的子消息，前提是它们是Message中的最后一个Submessage。

8.3.4. RTPS消息接收器（RTPS Message Receiver）

消息中的子消息的解释和含义可能取决于同一消息中包含的先前子消息。因此，Message的接收者必须记录同一Message中先前反序列化Submessage的状态。每次处理新消息时重置RTPS接收器的状态，并为每个Submessage的解析提供上下文环境。RTPS接收器如图2.11所示。表2.16列出了用于表示RTPS接收器状态的属性。

在这里插入图片描述
图 8 11 RTPS消息接收器

对于每个新消息（Message），接收器的状态将重置并初始化，如下所示。

表 8 16 接收器初始状态
在这里插入图片描述

8.3.4.1. 消息接收器遵循的规则

以下算法概述了任一消息（Message）接收器必须遵循的规则：

如果无法读取完整的Submessage报文头，则该消息的剩余部分将被视为无效。
submessageLength字段定义下一个Submessage的开始位置或指示Submessage延伸到Message的末尾，如2.3.3.2.3中所述。如果此字段无效，则消息的其余部分无效。
必须忽略具有未知SubmessageId的Submessage，并且必须继续解析下一个Submessage。具体来说：RTPS 2.2的实现必须忽略任何ID不在RTPS 2.2版规范定义的SubmessageKind集合当中的Submessages。vendorId不在供应商特定范围中的SubmessageIds也必须被忽略，并且必须继续解析下一个Submessage。
子消息标志（Submessage flags）。 Submessage的接收器应该忽略未知标志。 RTPS 2.2的实现应该跳过协议中标记为“X”（未使用）的所有标志。
必须始终使用有效的submessageLength字段来查找下一个Submessage，即使对于具有已知ID的Submessages也是如此。
已知但无效的Submessage使消息的其余部分无效。2.3.7描述了每个已知的Submessage以及何时应被视为无效。

接收有效报文头和/或Submessage有两个影响：

它可以改变接收器的状态; 此状态会影响消息中后续Submessages的解释方式。 2.3.7小节讨论了每个Submessage的状态如何变化。在此版本的协议中，只有Header和Submessages InfoSource，InfoReply，InfoDestination和InfoTimestamp会更改接收器的状态。
它可能影响消息目的端点的行为。这适用于基本的RTPS消息：Data，DataFrag，HeartBeat，AckNack，Gap，HeartbeatFrag，NackFrag。

8.3.7描述了报文头（Header）和每个子消息（SubMessage）的详细解释