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

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

关键字：OMG，RTPS，DDS

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

8.平台无关模型（PIM）

8.2 结构模块

8.2.2 RTPS HistoryCache

HistoryCache是DDS和RTPS之间接口的一部分，在读取者和写入者两端扮演着不同的角色。

在写入者这一端HistoryCache包含对相应DDS写入者对数据对象更改的部分历史记录，这些更改是为现有和未来匹配的RTPS 读取者端点提供服务所必需的。所需的部分历史记录取决于DDS QoS设置以及与匹配的RTPS读取者端点的通信状态。

在读取者端，它包含由所有匹配的RTPS 写入者端点对数据对象的部分更改的叠加。

“部分”一词用于表示不必保留所有更改的完整历史记录，需要的是满足RTPS协议的行为需求和相关DDS实体的QoS需求所需的历史记录的子集。定义该子集的规则由RTPS协议定义，并且取决于通信协议的状态和相关DDS实体的QoS。

HistoryCache是DDS和RTPS之间接口的一部分。换句话说，RTPS实体及其相关的DDS实体都能够在其关联的HistoryCache上调用方法。

图 8.3 RTPS HistoryCache类

HistoryCache属性在表8.3中列出。

表 8.3 RTPS HistoryCache属性

RTPS实体和相关的DDS实体使用表8.4中的方法与HistoryCache交互。

表 8.4 RTPS HistoryCache方法

以下子小节列出了上述方法的详细信息。

8.2.2.1 new

此方法将创建一个新的RTPS HistoryCache。 使用空的修改列表初始化新创建的历史记录缓存。

8.2.2.2 add_change

此方法将CacheChange a_change插入HistoryCache。

如果没有足够的资源将修改添加到HistoryCache，则此方法将调用失败。DDS服务实现负责以与DDS实体RESOURCE_LIMITS QoS一致的方式配置HistoryCache，并以DDS规范指定的方式将所有错误反馈给DDS用户。

此方法执行以下逻辑步骤：

ADD a_change TO this.changes;

8.2.2.3 remove_change

此方法表明先前添加的CacheChange已变得无关紧要，并且无需在HistoryCache中维护有关CacheChange的详细信息。基于与相关DDS实体相关联的QoS以及CacheChange的确认状态来确定不相关性，这在2.4.1中有所描述。

此方法执行以下逻辑步骤：

REMOVE a_change FROM this.changes;

8.2.2.4 get_seq_num_min

此方法获取存储在HistoryCache中的CacheChange中的CacheChange :: sequenceNumber属性的最小值。

此方法执行以下逻辑步骤：

min_seq_num := MIN { change.sequenceNumber WHERE (change IN this.changes) }
return min_seq_num;

8.2.2.5 get_seq_num_max

此方法获取存储在HistoryCache中的CacheChange中的CacheChange :: sequenceNumber属性的最大值。

此方法执行以下逻辑步骤：

	max_seq_num := MAX { change.sequenceNumber WHERE (change IN this.changes) }
	return max_seq_num;

8.2.3 RTPS CacheChange

用于表示添加到HistoryCache的每个更改的类。表8.5列出了CacheChange属性。

8.2.4. RTPS 实体（Entity）

RTPS实体是所有RTPS实体的基类，并映射到DDS实体。表8.6列出了实体（Entity）配置属性。

表 8.6 RTPS实体（Entity）属性

8.2.4.1. 识别RTPS实体：GUID

GUID（Globally Unique Identifier，全局唯一标识符）是所有RTPS实体都具有的属性，并唯一标识DDS域内的实体。

GUID构建为组合GuidPrefix_t前缀（prefix）和EntityId_t entityId的二元组< prefix，entityId>。

图 8.4 RTPS GUID_t唯一标识实体，由前缀和后缀组成

表 8.7 GUID_t的结构

8.2.4.2. RTPS参与者（Participants）的GUID

每个参与者都具有GUID< prefix, ENTITYID_PARTICIPANT>，其中常量ENTITYID_PARTICIPANT是由RTPS协议定义的特殊值。它的实际值取决于PSM。
只要确保域中的每个参与者都具有唯一的GUID，该实现就可以自由选择前缀。

8.2.4.3. 参与者中RTPS端点的GUID

具有GUID <participantPrefix，ENTITYID_PARTICIPANT>的参与者（Participant）包含的端点（Endpoint）具有GUID <participantPrefix，entityId>。entityId是端点相对于参与者的唯一标识。这会产生以下几种结果：

• 参与者（Participant）中所有端点（Endpoint）的GUID具有相同的前缀。
• 一旦知道端点（Endpoint）的GUID，包含端点的参与者（Participant）的GUID也是已知的。
• 任何端点（Endpoint）的GUID都可以根据其所属的参与者（Participant）的GUID及其entityId推断出来。

每个RTPS实体的entityId的选择取决于PSM。

---

译文连载

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

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

DDS规范-译文连载：DDS (Data Distribution Service) 数据分发服务-规范中文翻译_001

---

相关链接

DDS科普：一文读懂DDS（数据分发服务）

DDS定义：什么是DDS？

产品介绍：BLUE DCS分布式数据连接解决方案

产品试用： 海蓝云平台-Blue DCS