RTPS协议（二）Structure

烧烤王子

8.2.1 Overview

• RTPS的Entity是协议层的通信端点，被应用层的DDS Entity用以相互通信
  
• RTPS Entity与DDS Entity是一一对应的。
  
• RTPS Entity与DDS Entity间通过HistoryCache，以写操作为例：
  
  
  
  • 应用发起一次写操作请求
    
  • DDS DataWrtier向RTPS Writer的HistoryCache添加一个CacheChange
    
  • RTPS Writer将CacheChange传输到所有RTPS Reader的HistoryCache中
    
  • DDS DataReader从对应的RTPS Reader处获取到存在CacheChange的状态
    
  • 应用层通过读操作获取数据
    
  
  

8.2.1.1 RTPS虚拟机使用的类

• Entity：所有RTPS Entity的基类，RTPS Entity对象指拥有GUID，可被其他Entity可见的对象
  
• Endpoint：RTPS消息的起点/终点，特定的Entity
  
• Participant：所有RTPS Entity的容器，共享属性和地址空间
  
• Writer：特定的Endpoint，RTPS消息的起点
  
• Reader：特定的Endpoint，RTPS消息的终点
  
• HistoryCache：容器类，存储和管理内部数据对象的变化；并非完整的变化历史都需要被存储，数量取决于QOS和当前连接状态；
  
• CacheChange：表示对数据对象的单次修改，包括创建、修改、删除
  
• Data：表示数据对象变化关联的数据
  

8.2.1.2 RTPS虚拟机使用的数据类型

GUID	RTPS Entity的全局唯一标识符，必须可用16字节表示
GuidPrefix	GUID前缀，12字节表示，相同Participant下的Entity的GUID前缀一定相同
EntityId	与GuidPrefix共同组成GUID，用以区分同一个Participant下的不同Entity，4字节表示
SequenceNumber	64bits表示
Locator	RTPS Endpoint的寻址信息，用16字节描述地址，4字节描述端口或传输层标识符保留字：Invalid, Kind_Invalid, Reserved, Kind_UDPv4, Kind_UDPv6, Address_Invalid, Port_Invalid
TopicKind	枚举值区分是否数据实例中有key的字段
ChangeKind	枚举值区分对数据对象的修改的类型（包括数据修改和实例状态修改）
ChangeCount	HistoryCache中特定种类的数量
RealiabilityKind	通信可靠性的等级，BEST_EFFORT或RELIABLE
InstanceHandle	RTPS协议中传递的存在变化的数据对象的标识符
ProtocolVersion	RTPS协议版本号，PROTOCOLVERSION表示最近版本号
VendorId	实现RTPS协议的厂商

8.2.1.3 RTPS的配置属性  

RTPS的部分配置属性被映射到了DDS的QoS上，其他的可被配置以适应对应的传输场景，主要配置属性与上方的数据类型基本一致，其中对Writer和Reader的配置与协议行为紧密相关。



8.2.2 RTPS HistoryCache

Writer端：HistoryCache包含了Writer对数据对象的修改内容的一部分
Reader端：包含配对的Writer的数据对象修改内容中的一部分
HistoryCache是DDS与RTPS交互接口的一部分，因此RTPS和DDS的Entity都可以操作对应的HistoryCache。
相关的接口如下图所示，HistoryCache内部的属性为CacheChange指针类型，表示内部的修改内容列表；其中new操作是创建一个新的HistoryCache，add_change和remove_change是向HistoryCache中增加或删除CacheChange。




8.2.3 RTPS CacheChange

CacheChange类的属性如下

ChangeKind	Change类型	DDS state Kind
GUID	引起change的Writer的GUID
InstanceHandle	被修改的数据对象的ID	DDS data-object Key
SequenceNumber	Change的标识符
Data	具体的修改内容数据段
ParameterList	可能影响Data数据段的表示的QoS	DDS specific info

8.2.4 RTPS Entity

RTPS Entity是一个基类，可以映射到DDS Entity，其属性只有一个：GUID，表示在DDS Domain内其唯一标识符，GUID内包括GuidPrefix（标识Participant）和EntityId（标识Entity）。




对于RTPS Participant、Participant内部的EndPoint Groups和RTPS EndPoint，其GUID中的Prefix都和Participant的一致。
8.2.5 RTPS Participant

Participant是RTPS Group的容器，Group是Endpoint的容器，对应DDS中的DomainParticipant。




Participant类的属性如下

UnicastLocator	单播地址的默认列表，当Endpoint未确定Locator时使用	Discovery过程配置
MulticastLocator	多播地址的默认列表，当Endpoint未确定Locator时使用	Discovery过程配置
ProtocolVersion	RTPS协议版本号
VendorId	RTPS中间件供应商

8.2.6 RTPS Group

包括两种Group Entity：Publisher、Subscriber
映射关系：

• RTPS Publisher ~ RTPS Writer ~ DDS Publisher
  
• RTPS Subscriber ~ RTPS Reader ~ DDS Subscriber
  

8.2.7 RTPS Endpoint

UnicastLocator	用于向Endpoint发送消息的单播地址的列表，可为空	Discovery过程配置
MulticastLocator	用于向Endpoint发送消息的多播地址的列表，可为空	Discovery过程配置
ReliabilityKind	Endpoint支持的可靠性等级	对应DDS的Reliability QoS
topicKind	用来表示Endpoint是否支持实例生命周期管理操作	由对应的DDS Topic关联的Datatype定义，标识Endpoint是否与Datatype相关
EntityId	表示Endpoint属于哪一个RTPS Group	关联DDS的Publisher或Subscriber

8.2.8~8.2.9 RTPS Writer & Reader  

一个Endpoint的实例，功能是通过HistoryCache发送CacheChange给对应的Reader/Writer。
一个RTPS Writer/Reader隶属于一个RTPS Publisher/Subscriber Group。
8.2.10 DDS Entity和RTPS Entity的交互  

注意到RTPS协议中并不会规定DDS Entity如何和HistoryCache交互，而只关注CacheChange如何从RTPS Writer的HistoryCache传递到RTPS Reader的HistoryCache，但我们仍然是需要了解DDS如何从HistoryCache中获取信息的，整个过程可以参考下面的时序：

• DDS DataWriter将CacheChange添加到对应RTPS Writer的HistoryCache中
  
• RTPS Writer将自己的HistoryCache中的所有CacheChange全部发送至对应的RTPS Reader的HistoryCache中
  
  
  • 存在DDS DataWriter将CacheChange移除的可能
    
  
  
• RTPS Reader的HistoryCache中的所有CacheChange经过过滤后，通过DDS Reader的read或者take方法，全部被提取出来。
  

古月西乡

介是神马？！！