FastRTPS原理与代码分析（3）：动态发现协议之端点发现协 议EDP
分析EDP交互码流（No.75~No.109）前，先说明下图图3-1码流中各个⼦消息的功能。 图3-1 发布端和订阅端匹配完整码流
名称功能
INFO_TS指⽰该条RTPS消息被发送时的时间戳。 INFO_DST指⽰在该条RTPS消息中，INFO_DST后⾯的⼦消息的处理者
RTPS reader实体的GuidPrefix为INFO_DST.GuidPrefix。
DATA(p)数据消息，包含参与者的属性信息，即PDP消息。
DATA(w)数据消息，包含userWriter的属性信息。当发布端
userWriter创建成功后，该消息会被发送给订阅端。
DATA(r)数据消息，包含userReader的属性信息。当订阅端
userReader创建成功后，该消息会被发送给发布端。
DATA数据消息，包含⽤户发送的实际消息内容。
HEARTBEAT该消息有两个功能：
1.它通知Reader在Writer的历史缓存中可⽤的序列号，
这样Reader就可以请求（使⽤⼀个AckNack消息）任何已经
错过的内容。
2.它要求Reader发送对已进⼊Reader历史缓存的
CacheChange更改的确认，以便Writer了解Reader的状
态。
所有Heartbeat消息都有第⼀个功能。也就是
说，Reader总是会发现writer的HistoryCache的状态，并可
说，Reader总是会发现writer的HistoryCache的状态，并可
能请求它所遗漏的内容。通常，如果它丢失了⼀个
CacheChange，RTPS Reader会发送⼀个AckNack消息。
Writer使⽤FinalFlag请求Reader对它收到的序列号发送
确认信息。如果Heartbeat设置了FinalFlag，那么Reader就
不需要回AckNack消息了。但是，如果没有设置FinalFlag，
那么Reader必须发送⼀个AckNack消息，指⽰它已经接收到
哪些缓存更改，即使AckNack指出它已经在Writer的历史缓
存中获得了所有的CacheChange更改。
ACKNACK该⼦消息⽤于将Reader的状态通知Writer。该⼦消息允
许Reader告知Writer所收到的序列号，以及它仍然缺少的序
胥荣东
列号。这个⼦消息可以⽤来做正常应答以及异常应答。
ACKNACK消息中元素readerSNState，所有在
readerSNState.base之前的序列号是已经被Reader确认收
到的。出现在集合⾥⾯的序列号是Reader没有收到的序列
号。
图3-2 端点消息交互图
图3-2 中的所有的Writer和Reader端点，⼜分为有状态端点和⽆状态端点。PDP的2个端点是⽆状态端点。EDP和WLP的6个端点都是有状态端点，UserWriter和UserReader端点由于在本⽰例当中Qos设置的是可靠传输，所以他们也是有状态端点。
有状态Writer和Reader建⽴关联的消息交互如图3-3所⽰。
图3-3 StatefulWriter和StatefulReader建⽴关联消息交互图
图中缩写意义如下：
缩写含义
HB HEARTBEAT消息。
ACK ACKNACK消息。
INIT_ACK初始化ACKNACK消息。
析氢腐蚀
如图3-4所⽰。
该消息在StatefulReader匹配⼀个StatefulWriter的时候被发
送。当StatefulWriter收到该消息时，响应HEARTBEAT消息。
正丁醇
图3-4 初始化ACKNACK消息
图3-3 中5条消息的详细描述如下：
1. 通过收到对端的PDP消息，Writer获取到对端对应的Reader的属性信息。这时给该Reader发送HEARTBEAT消息。
2. Reader收到了Writer的HEARTBEAT消息，响应ACKNACK消息。
小康网络大学
3. 当Reader通过PDP消息，获取到了对端对应的Writer的属性信息，这时发送初始化ACKNACK给对端Writer。
4. Writer收到初始化ACKNACK消息，响应HEARTBEAT消息。
5. Reader收到HEARTBEAT消息，响应ACKNACK消息。
所以理论上⼀对StatefulWriter和StatefulReader建⽴关联会产⽣5条RTPS消息，其中HEARTBEAT两条，ACKNACK三条。另外，StatefulWriter和StatefulReader建⽴关联，发送消息的顺序不会严格和图3-3中的⼀致，和实际测试环境相关。
注意，为什么说是理论上，因为有可能少于5条。图3-3中蓝⾊的ACKNACK消息，有可能Reader不会发送，原因是Reader接收Writer的HEARTBEAT消息并响应ACKNACK消息的前提是，Reader已经匹配了该Writer，如果在接收到Writer的HEARTBEAT消息时，Reader还没有完成和该Writer的匹配，那么HEARTBEAT消息会被Reader丢弃，同时Reader也不会响应ACKNACK消息。这种情况是存在的，幸运的是本篇博客中截取码流的这次测试，所有有状态端点的交互都没有出现这种情况。笔者测试过多次，实际上这种情况出现的概率很⾼。
StatefulReader接收到StatefulWriter的HEARTBEAT消息时，判断是否匹配的代码段如下：
EDP和WLP⼀共6对有状态端点，建⽴连接理论上会产⽣30条RTPS消息。HEARTBEAT⼀共12条，ACKNACK⼀共18条。
图3-1中，从编号75到编号107的RTPS码流对应的正好是EDP和WLP的6对有状态端点建⽴连接的码流。⼀共30条RTPS消息。具体消息数分类如下：
类型数量总计
HEARTBEAT6对* 每对发送2条12
ACK6对* 每对发送2条12（有可能少于12，原因前⾯已经
描述过）
6对* 每对发送1条6
ACK（初始化
ACK）
具体EDP和WLP端点消息交互可以参考图3-4的编号75到107。
何其莘图3-5消息交互和图3-1的wireshark码流是对应的。
图3-5 EDP和WLP端点消息交互图
EDP和WLP的端点都是通过对端发来的PDP消息，获取对端端点的属性信息。然后进⾏消息交互，建⽴关联。
EDP和WLP的端点都完成关联了，然后轮到UserWriter和UserReader建⽴关联。
UserWriter在被创建时，它的属性信息被封装成数据，存放在发布端EDP的SEDPPubWriter的历史缓存中。UserWriter被创建时调
⽤堆栈如下：
⽤堆栈如下：
