通信易懂唠唠SOME/IP——SOME/IP-SD服务发现阶段和应答行为
一 SOME/IP-SD服务发现阶划分
服务发现应该包含3个阶段
1.1 Initial Wait Phase初始等待阶段
- 初始等待阶段的作用
初始等待阶段是服务发现过程中的一个阶段。在这个阶段，服务发现模块等待服务实例的相关条件满足，以便继续后续的发现和注册过程。
对于客户端服务实例，当务实例所需的网络接口链接已经建立，即网络接口处于 "up" 状态且应用需要这个服务时即进入初始等待阶段。
在实际的实现中，应用需要某个服务一般是生成到配置文件中，当配置文件中有这个实例id，就认为应用需要这个服务。
对于服务器端服务实例，当务实例所需的网络接口链接已经建立，即网络接口处于 "up" 状态且服务可用。即服务器服务已经启动并准备好接受请求。服务准备好一般和具体功能有关系，比如camera service等camera初始化完成。
- 初始等待阶段的等待时间INITIAL_DELAY
初始等待阶段等待的时间取决于INITIAL_DELAY值得设置。NITIAL_DELAY应该设置一个最大值和一个最小值，实际等待时间是介于最大值和最小值之间的一个随机值。
下面重复阶段和主阶段都是以Provider instance为例的，request insatnce类似，后面会对不一样的地方单独说明。
1.2 Repetition Phase重复阶段
初始等待阶段等待时间到了之后，会发送第一条offer service消息，这时候就进入了重复阶段。
进入重复阶段后
第一次等待REPETITIONS_BASE_DELAY时间后发送第二条offer service消息
然后在等待上一次等待时间的2倍时间发送下一条offer service消息。
如此重复，最大重复次数为REPETITIONS_MAX。这里参数比较多不好理解,可以结合1.5部分的例子增加理解。。
1.3 Main Phase 主阶段
重复阶段结束之后，立马进入在主阶段，先等待1*CYCLIC_OFFER_DELAY时间发送offer service消息，之后以CYCLIC_OFFER_DELAY配置的周期，周期发送offer service 消息。
1.4 client service insatnce的三个阶段
上面是以server端instance为例说明的三个阶段，对于client instance类似。
初始等待阶段和重复阶段与服务端instance类似，只不过发的是find service报文。
不同之处是，find service没有主阶段，即重复阶段之后就不会再发送find 报文了。
Subscribe EventGroup Entries由周期offer service触发，也是周期发送。所以在主阶段我们会看到周期的Offer Service报文和周期的Subscribe报文。
1.5举个例子：
上图是server service instance的各个参数,INITIAL_DELAY的最大值和最小值分别为0.1秒和0.01秒。REPETITIONS_BASE_DELAY是0.5秒，REPETITIONS_MAX是3。按照配置预期的服务发现的行为是：
1）Initial Wait Phase：服务实例化--》等待0.01秒~0.1秒之间的一个时间
2）Repetition Phase：然后发送第一帧数据（即offer service报文）--》延时2^0*0.5s=500ms-》发送offer service--》延时2^1*0.5s=1s时间--》发送offer service--》延时2^2*0.5s=2s时间-》发送offer service。即重复发3次offer service，共发4次报文，每次等待时间是上一次的两倍。
3）Main Phase：之后按照3秒周期发送
抓到报文也确实如我们所想
上图第二列是距离上一帧数据的时间，单位秒，可以发现与预期现象一致
第一次offer service
第二次时间-第一次时间约等于500ms
第三次时间-第二次时间约等于1s
第四次时间-第三次时间约等于2s
之后时间间隔都是约等于3s
这样设计的意义也很好理解，即发送的频率越来越慢，如果一开始发送的频率慢，不利于找到服务，如果一直高频率发送，又增加网络负载。
二 服务发现Answer Behavior应答行为
服务发现阶段的应答行为
- 服务端收到find service entry后回复offer service entry
服务端收到find service entry的unicast falg=1,且收到find service的时间距离上一次发送offer service的时间<1/2 的CYCLIC_OFFER_DELAY，则回复一个单播offer service。
服务端收到find service entry的unicast falg=1,且收到find service的时间距离上一次发送offer service的时间>=1/2 的CYCLIC_OFFER_DELAY，则回复一个多播的offer service。
如果REQUEST_RESPONSE_DELAY值设置为0，则是立即回复offer service。
如果REQUEST_RESPONSE_DELAY值不是0，则是delay一个介REQUEST_RESPONSE_DELAY最大值和最小值之间的一个值再回复单播offer service。
- 客户端收到多播offer service entry后回复单播subscribe entry
如果REQUEST_RESPONSE_DELAY值设置为0，则是立即回复单播subscribe entry。
如果REQUEST_RESPONSE_DELAY值不是0，则是delay一个介 REQUEST_RESPONSE_DELAY最大值和最小值之间的一个值再回复单播subscribe entry
- 客户端收到单播offer service entry后回复单播subscribe entry
此种情况不受REQUEST_RESPONSE_DELAY的影响