一 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的影响