8.1 说明
本条款定义了RTPS协议的平台独立模型，后续条款将PIM映射到各种平台，最基本的平台是本机UDP数据包。
引入 RTPS 虚拟机的唯一目的是以完整且明确的方式描述协议。此描述并非旨在以任何方式限制内部实现。合规实现的唯一标准是外部可观察的行为满足互操作性的要求。具体而言，实现可以基于其他类，并且可以使用除状态机之外的编程结构来实现 RTPS 协议。
8.2 Structure模块
本小节主要描述通信参与者的RTPS实体结构。
8.2.1 概述
RTPS实体是应用程序可见的DDS实体用于相互通信的协议级端点。
每个RTPS实体与DDS实体一一对应，HistoryCache是构成DDS实体与其对应的RTPS实体之间的接口。DDS DataWriter 上的每个写入操作都会将 CacheChange 添加到其对应的 RTPS Writer 的 HistoryCache 中。RTPS Writer 随后将 CacheChange 传输到所有匹配的 RTPS Reader 的 HistoryCache 中。在接收端，RTPS Reader 会通知 DDS DataReader，新的 CacheChange 已到达 HistoryCache，此时 DDS DataReader 可以选择使用 DDS 读取或获取 API 来访问它。
8.2.1 RTPS虚拟机使用的类
所有RTPS实体都派生自RTPS实体类。
RTPS虚拟机使用的类：
| 类 | 作用 |
|---|---|
| Entity | 所有 RTPS 实体的基类。RTPS 实体表示网络上其他 RTPS 实体可见的对象类。因此，RTPS 实体对象具有全局唯一标识符 (GUID)，可在 RTPS 消息中引用。 |
| Endpoint | RTPS 实体的特化，表示可以作为通信端点的对象。也就是说，可以作为 RTPS 消息的源或目标的对象。 |
| Participant | 所有具有共同属性且位于单一地址空间的 RTPS 实体的容器。 |
| Writer | RTPS Endpoint的特化，表示可以用于与CacheChanges通信消息源的对象 |
| Reader | RTPS Endpoint的特化，表示可以用于接收与CacheChanges通信的消息的对象 |
| HistoryCache | 容器类，用于临时存储和管理对数据对象的更改集。在Writer端，它包含写入器对数据对象所做的更改的历史记录。没有必要维护所有更改的完整历史记录，相反，需要的是服务现有和未来匹配的 RTPS 读取器端点所需的部分历史记录，所需的部分历史记录取决于 DDS QoS 和与匹配的Reader端点的通信状态。在Reader端，它包含匹配的 RTPS Writer端点对数据对象所做的更改的历史记录，没有必要维护所有收到的更改的完整历史记录，相反，需要的是包含从匹配的Writer接收到的更改的叠加的部分历史记录，以满足相应 DDS DataReader的需求。此叠加的规则和所需的部分历史记录量取决于 DDS QoS 和与匹配的 RTPS Writer端点的通信状态。 |
| CacheChange | 表示对数据对象所做的单个更改。包括数据对象的创建、修改和删除。 |
| Data | 表示可能与数据对象所作的更改相关的数据。 |
描述RTPS实体和类的类型
| 属性 | 作用 |
|---|---|
| GUID_t | 用于保存全局唯一 RTPS 实体标识符的类型。这些标识符用于唯一地引用系统中的每个 RTPS 实体。必须能够使用 16 个八位字节表示。协议保留以下值：GUID_UNKNOWN |
| GuidPrefix_t | 用于保存全局唯一 RTPS 实体标识符前缀的类型。属于同一参与者的实体的 GUID 都具有相同的前缀。必须能够使用 12 个八位字节表示。协议保留以下值：GUIDPREFIX_UNKNOWN |
| EntityId_t | 用于保存全局唯一 RTPS 实体标识符后缀部分的类型。EntityId_t 唯一标识参与者内的实体。必须能够使用 4 个八位字节表示。协议保留以下值：ENTITYID_UNKNOWN |
| SequenceNumber_t | 用于保存序列号的类型。必须能够使用 64 位表示。协议保留以下值：SEQUENCENUMBER_UNKNOWN |
| Locator_t | 用于表示使用受支持的传输方式之一向 RTPS 端点发送消息所需的寻址信息的类型。应能够保存用于识别传输方式、地址和端口号的鉴别符。必须能够分别使用 4 个八位字节表示鉴别符和端口号，使用 16 个八位字节表示地址。协议保留以下值：LOCATOR_INVALID、LOCATOR_KIND_INVALID、LOCATOR_KIND_RESERVED、LOCATOR_KIND_UDPv4、LOCATOR_KIND_UDPv6、LOCATOR_ADDRESS_INVALID、LOCATOR_PORT_INVALID |
| TopicKind_t | 枚举用于区分主题是否已定义一些字段，这些字段将用作标识主题内数据实例的“键”。协议保留以下值：NO_KEY、WITH_KEY |
| ChangeKind_t | 用于区分对数据对象所做的更改类型的枚举。包括对数据或数据对象实例状态的更改。它可以采用以下值：ALIVE、ALIVE_FILTERED、NOT_ALIVE_DISPOSED、NOT_ALIVE_UNREGISTERED |
| ChangeCount_t | 用于保存表示属于特定类别的 HistoryCache 更改数量的计数器的类型。例如，已为 RTPS Reader 端点过滤的更改数量。 |
| ReliabilityKind_t | 用于指示通信可靠性级别的枚举。它可以采用以下值：BEST_EFFORT、RELIABLE。 |
| InstanceHandle_t | 用于表示数据对象身份的类型，该数据对象值的变化通过 RTPS 协议进行传达。 |
| ProtocolVersion_t | 用于表示 RTPS 协议版本的类型。版本由主版本号和次版本号组成。协议保留以下值：PROTOCOLVERSION、PROTOCOLVERSION_1_0、PROTOCOLVERSION_1_1、PROTOCOLVERSION_2_0、PROTOCOLVERSION_2_1、PROTOCOLVERSION_2_2、PROTOCOLVERSION_2_4、PROTOCOLVERSION 是最新版本的别名，在本例中为PROTOCOLVERSION_2_4 |
| VendorId_t | 用于表示实施 RTPS 协议的服务供应商的类型。vendorId 的可能值由 OMG 分配。协议保留以下值：VENDORID_UNKNOWN |
RTPS实体的配置属性
RTPS 实体由一组属性配置。其中一些属性映射到在相应 DDS 实体上设置的 QoS 策略。其他属性表示允许根据特定传输和部署情况调整协议行为的参数。其他属性对 RTPS 实体的状态进行编码，并且不用于配置行为。
下图显示了用于配置 RTPS 实体子集的属性。配置写入器和读取器实体的属性与协议行为密切相关。
8.2.2 RTPS HistoryCache
HistoryCache是RTPS和DDS之间接口的一部分，在读取器和写入器之间扮演不同的角色。
在写入器端，HistoryCache 包含相应 DDS 写入器对数据对象所做的更改的部分历史记录，这些更改是服务现有和未来匹配的 RTPS 读取器端点所必需的。所需的部分历史记录取决于 DDS Qos 和与匹配的 RTPS 读取器端点的通信状态。
在读取器端，它包含所有匹配的 RTPS 写入器端点对数据对象所做的更改的部分叠加。
“部分”一词用于表示没有必要保留所有更改的完整历史记录。相反，需要的是满足 RTPS 协议的行为需求和相关 DDS 实体的 QoS 需求所需的历史记录子集。定义此子集的规则由 RTPS 协议定义，并且取决于通信协议的状态和相关 DDS 实体的 QoS。
HistoryCache 是 DDS 和 RTPS 之间接口的一部分。换句话说，RTPS 实体及其相关的 DDS 实体都能够调用其关联的 HistoryCache 上的操作。
RTPS HistoryCache属性：
| 属性 | 类型 | 含义 | 与DDS的关联 |
|---|---|---|---|
| changes | CacheChange[*] | HistoryCache中包含的CacheChange列表 | N/A |
RTPS HistoryCache 操作：
| 操作名 | 参数列表 | 参数类型 |
|---|---|---|
| new | HistoryCache | |
| add_change | void | |
| a_change | CacheChange | |
| remove_change | void | |
| a_change | CacheChange | |
| get_seq_num_min | SequenceNumber_t | |
| get_seq_num_max | SequenceNumber_t |
new: 创建一个新的RTPS HistoryCache，这个新创建的HistoryCache被初始化成一个空的change列表
add_change：在HistoryCache中插入一个CacheChange，只有在HistoryCache中没有足够空间去加入一个change时，该操作才会失败，DDS 服务实现有责任以与 DDS 实体 RESOURCE_LIMITS QoS 一致的方式配置 HistoryCache，并以 DDS 规范指定的方式将任何错误传播给 DDS 用户。该操作的逻辑步骤：ADD a_change TO this.changes;
remove_change：表示从 HistoryCache 中删除先前添加的 CacheChange，并且无需在 HistoryCache 中维护有关 CacheChange 的详细信息。从缓存中删除哪些更改的决定取决于与相关 DDS 实体关联的 QoS 以及 CacheChange 的确认状态。该操作的逻辑步骤：REMOVE a_change FROM this.changes;
get_seq_num_min：检索 HistoryCache 中存储的 CacheChange 中 CacheChange::sequenceNumber 属性的最小值。该操作的逻辑步骤：min_seq_num := MIN { change.sequenceNumber WHERE (change IN this.changes) }
return min_seq_num;
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：
该类是将每个变化的change填加到HistoryCache中，具体成员见下表：
| 属性 | 类型 | 含义 | 与DDS的关系 |
|---|---|---|---|
| kind | ChangeKind_t | 表示change类型 | DDS实例状态类型 |
| writerGuid | GUID_t | 表示RTPS Writer的变化 | N/A |
| instanceHandle | InstanceHandle_t | 表示应用于哪个数据对象 | 在DDS中作为每个数据对象的key |
| sequenceNumber | SequenceNumber_t | RTPS writer分配的序列号，表示唯一的change | N/A |
| data_value | Data | 与change向关联的值，依赖CacheChange的类型，可能没有关联值 | N/A |
| inlineQos | ParameterList | 包含可能影响CacheChange::data_value解释的Qos | 影响数据的DDS特定信息 |
8.2.4 RTPS实体
RTPS实体是指所有RTPS实体的基类并映射到DDS实体。
| 属性 | 类型 | 含义 | 与DDS的关系 |
|---|---|---|---|
| guid | GUID_t | DDS域内全局唯一标识RTPS的实体 | 映射到用于描述相应DDS实体的BuiltinTopicKey_t的值 |
GUID是一个<prefix, entityId>的tuple，prefix类型为GuidPrefix_t，entityId类型为EntityId_t
| 变量名 | 类型 | 含义 |
|---|---|---|
| prefix | GuidPrefix_t | Domain中Participant的唯一标识 |
| entityId | EntityId_t | Participant中Entity的唯一标识 |
RTPS participant的GUID：
每个Participant都有一个GUID<prefix, ENTITYID_PARTICIPANT>，ENTITYID_PARTICIPANT是一个常数，由RTPS协议定义，它的实际值依赖于PSM。
只要Domain内每个Participant都有唯一的GUID，那么prefix可以自由选择。
Participant中Endpoint Groups的GUID：
Endpoint Groups包含在一个RTPS Participant中，Endpoint Groups的GUID为<participantPrefix, entityId>，entityId是Group相对于Participant的唯一标识，这会导致以下几种情况：
- Participant中的所有Group的GUID都有相同的prefix
- 一旦Group的GUID已知，那么包含端点的Participant的GUID也会已知
- 任何Group的GUID都可以从它所属的Participant的GUID以及其entityId推断出来，每个RTPS的实体的entityId的选择取决于PSM
Participant中RTPS Endpoint的GUIID：
Endpoint所属Participant的GUID为<participantPrefix, entityId>，该entityId是Endpoint相对于Participant的唯一标识，这将导致以下几种情况：
- Participant中所有Endpoint的GUID都有相同的prefix
- 一旦Endpoint的GUID已知，那么participant所包含的Endpoint的GUID也会已知
- 任何Endpoint的GUID可以从它所属的Participant的GUID以及其entityId推断出来，每个RTPS实体的entityId的选择取决于PSM
8.2.5 RTPS Participant
RTPS Participant是RTPS Group实体的容器，它里面包含Endpoint实体，RTPS Participant映射到DDS DomainParticipant。
| 属性 | 类型 | 含义 | 与DDS的联系 |
|---|---|---|---|
| defaultUnicastLocatorList | Locator_t[*] | 默认单播地址列表，可以给Endpoint中包含的Participant发送消息，Endpoint未指定locator时使用该默认单播地址列表 | N/A，由discover模块设置 |
| defaultMulticastLocatorList | Locator_t[*] | 默认多播地址列表，可以给Endpoint中包含的Participant发送消息，Endpoint未指定locator时使用该默认多播地址列表 | N/A，由discovery模块设置 |
| protocolVersion | ProtocolVersion_t | 标识RTPS的版本号 | N/A，每个协议版本一个版本号 |
| vendorId | VendorId_t | 标识RTPS中间件的供应商 | N/A，由每个供应商配置 |
8.2.6 RTPS Group
RTPS Group是RTPS Endpoint实体的容器，它为RTPS Endpoint实体提供了一种共享公共属性的方法。
RTPS Group实体有两种类型：publisher和subscriber：
- RTPS Publisher包含RTPS Writer端点，RTPS Publisher映射到DDS Publisher
- RTPS Subscriber包含RTPS Reader端点，RTPS Subscriber映射到DDS Subscriber
8.2.7 RTPS Endpoint
RTPS端点代表从RTPS协议角度来看可能通信的端点，有两种类型的RTPS端点：Writer端点和Reader端点。
RTPS Writer端点发送CacheChange给RTPS Reader端点，并且潜在地接收确认他们发送的change。RTPS Reader端点接收CacheChange和更改可用性公告，并可能确认更改和/或错过的请求。
| 属性 | 类型 | 含义 | 与DDS的关联 |
|---|---|---|---|
| unicastLocatorList | Locator_t[*] | 单播地址列表。用来给端点发送消息，该列表可能为空 | N/A，由Discovery模块配置 |
| multicastLocatorList | Locator_t[*] | 多播地址列表。用来给端点发送消息，该列表可能为空 | N/A，由Discovery模块配置 |
| reliabilityLevel | ReliabilityKind_t | 端点支持的reliable等级 | 对应RELIABILITY QoS的类型 |
| topicKind | TopicKind_t | 用来指示端点是否支持实例生命周期管理操作 | 由DDS Topic相关的RTPS端点的数据类型定义，表明端点是否与已将某些字段定义为包含DDS键的数据类型关联 |
| endpointGroup | EntityId_t | 表明RTPS Group属于哪个端点 | 表明DDS Publisher或Subscriber关联的RTPS端点 |
8.2.8 RTPS Writer
8.2.9 RTPS Reader
8.3 Messages模块
8.4 Behavior模块
8.5 Discovery模块
8.6 版本及扩展性
8.7 RTPS实现DDS qos和高级DDS特性
3991
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
