DDS-RTPS 常见子消息

PDP数据

上图中有个注释有错误，就是元数据通信的那段，这个通信地址和端口值是给EDP使用的

下图是PID_BUILTIN_ENDPOINT_SET中的内容，标识了该Participant有哪些内建的Entpoint（用于元数据通信）

从实际抓包数据中PDP数据包的发送时间看，PDP的发送间隔是100毫秒。

INFO_DST:

除了PDP数据意外，DDS发送的其他主要的子消息（EDP， DATA，DATA(w)，DATA(r)以及HeartBeat心跳，ACKNACK应答）都是需要在子消息前面加上INFO_DST，用于标记在IFNO_DST下面的子消息中的readerEntity是属于那个Participant的（根据GuidPrefix）

因此，INFO_DST子消息的结构比较简单，最重要的一个子元素就是GuidPrefix，这个GuidPrefix加上根在后面的HeartBeat/AckNack/Data(w)/Data(r)子消息中的ReaderEntityID，就可以确定INFO_DST子消息下面一条子消息是发给哪一个Reader的（GuidPrefix + EntityID）

EDP数据：

EDP数据也是放在Data子消息中的，一般会有（r）或者（w）标记标识这个子消息中放的是Publisher还是Subscriber的信息（用户创建的Subscriber/publisher)

EDP数据是Participant将内部Writer或者Reader的信息发布给对端Participant，同时接收对端发送的EDP数据了解对端Participant中创建的Writer或者Reader，进而进行下一步Reader/Writer的匹配。

EDP数据Writer/Reader的信息在Data子消息的SerializedData元素中，其中包含了Writer/Reader的信息：

心跳包：

心跳包的作用是Writer将自己History中的Change的情况告知匹配的对端Reader，然后接收Reader的ACKNACK消息，来判断是否需要发送Reader丢失没有收到的Change。

心跳包中是不带有实际的Change数据的，实际的Change数据是放在Data子消息中单独发送的。

心跳包中比较重要的信息就是history中可读取的第一包Change的序列号 (firstAvaliableSeqNumber)以及最后一包可读取的Change的序列号(lastSeqNumber)。

根据HeartBeat子消息中的readerEntityID和writerEntityID可以判断出这个心跳包用于EDP数据的还是用户业务数据的。

ACKNACK：

ACKNACK是对心跳包的回应，首先根据心跳包中的readerEntityId获知这个心跳包是针对哪个Reader的？然后根据心跳包中的firstAvaliableSeqNumber以及lastSeqNumber判断有没有Reader没有读取到的Change。

如果心跳包中的存在有Reader没有读取到的Change，则需要将这些Change的序号收集起来放到ACKNACK消息中，其中要告知对端Writer我的Reader缺少了这些Change，这些Change的序号从A开始，然后有B个Change。

反映在ACKNACK报文里面，A和B都填写在ACKNACK子消息的readerSNState元素中，如下图：

其中，bitmapBase就是缺失的Change的起始序号，而numBits就是缺失的Change的数量:

如果收到心跳包后，发现Reader没有未读取的Change，这时还是需要回复ACKNACK子消息给对端的，只是里面的起始序号会是心跳包中lastSeqNumber+1，然后缺失的Change的数量为0

Data(用户业务数据)：

通过用户创建的Endpoint（Writer）发送的Data子消息就是用户业务数据，一个RTPS消息中可能包含多个Data子消息（例如收到对端的ACKNACK消息中缺失多条Change）

每一条Data子消息前面都会有一条DATA_TS子消息，用于标注该Data子消息的发送时间。

下图是包含多个Change数据的消息（多个DATA和DATA_TS子消息）：