SOMEIP协议--第二节[SOME/SD](SD概述与SD行为)

起风就扬帆

已于 2023-07-22 10:47:33 修改

阅读量8.3k

点赞数 16

CC 4.0 BY-SA版权

分类专栏： someip协议文章标签： tcp/ip 网络 someip

于 2023-07-22 10:38:23 首次发布

本文链接：https://blog.csdn.net/qq_41816308/article/details/131864293

someip协议专栏收录该内容

8 篇文章 ¥39.90 ¥99.00

订阅专栏

超级会员免费看

本文详细介绍了SOME/IP协议中的服务发现（SD）概念，包括服务发布的两种形式——一次性购买和订阅。SD流程通过服务发布、服务订阅和事件通信实现进程间通信。此外，文章还探讨了Local Service Discovery、服务发现的状态机以及服务器和客户端SD的行为，强调了SD在服务保活和资源管理中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

SOME/IP协议----第二节SOME/SD

SOMEIP/SD

1、SD概述

1.1、服务发现（简称SD)

服务发现（简称SD)，主要有两个作用:
1、实现服务发布和订阅行为
2、管理某个服务实例(包括服务端和客户端）是否需要运行或者是否能够发送报文

1.2、服务发现流程：

服务发现的流程就像是食堂卖饭的过程，可以分为两种形式，一次性购买或者订阅（订餐）。一次性购买可以将食堂看成服务端，用户看成客户端。
首先食堂会通过广告（广播）等的形式告诉大家我有哪些食品可以买。如果客户小王想到吃某个饭的时候，就主动到食堂，买一份饭回来吃即可。
订阅可以将食堂看成食品提供方，用户看成食品的消费方;首先食堂同样会通过广告（组播）的形式告诉大家我有哪些食品可以买。这次客户小王觉得每次去买太麻烦了，可以订阅食品，那么每次到饭点的时候，就会有跑腿将食品送过来。
那么我们将一次性购买的流程看成两个步骤:
1.食堂通知大家自己有哪些食品(服务发布)
2.小王收到通知后，购买食品，然后吃饭。
我们将订阅购买的流程看成三个步骤:
1.食堂通知大家自己有哪些食品(服务发布)
2.小王收到通知后，打电话告诉食堂他要订阅某某食品(服务订阅)
3.食堂送饭的时候主动送到小王家，小明在家拿到饭。
另外服务发现还有一个作用是管理服务的运行或者使能收发报文。比如食堂没有人吃饭，订餐食堂可以休息，等有人买再开始。对应计算机就是节省资源。

2、someip/SD的行为

2.1、Local Service Discovery

SOME/IP协议的“Local Service Discovery”模式是通过UDP广播来发现服务，并使用基于UDP的点对点通信来进行进程间通信。
当一个进程需要访问另一个进程的服务时，它会向本地的SOME/IP服务代理发送一个请求，服务代理会在本地的服务目录中查找并返回符合条件的服务列表。然后，请求方可以通过发送基于UDP的点对点消息来与服务提供方进行通信，从而实现进程间通信。
整体过程：
当服务请求者发起服务请求时，服务代理会先在本地维护的服务目录中查找是否有符合条件的服务提供者。如果本地服务目录中存在对应的服务提供者，则服务请求者可以直接通过UDP点对点通信方式向服务提供者发送服务请求和响应消息，完成服务调用的过程。如果本地服务目录中没有找到对应的服务提供者，则服务代理会通过UDP广播方式向网络中的其他节点发送服务请求，以便寻找服务提供者。在这种情况下，服务请求者需要等待一定时间，等待其他节点的响应。如果在规定的时间内没有收到响应，则服务请求者会抛出服务不可用的异常。如果找到了服务提供者，则服务请求者会通过UDP点对点通信方式向服务提供者发送服务请求和响应消息，完成服务调用的过程。

2.2、服务发现的流程主要分为两种

1、服务的寻找与发布流程，主要用于Method通信。
2、服务的寻找、发布与订阅流程，主要用于Event通信。

2.2.1、服务发布与Method通信

服务的发布流程即某个服务上线后，可以在运行时动态的通知到大家，然后需要使用该服务的客户遍可以请求该服务了。someip协议对于服务的发布规定使用offer报文来表示，服务的寻找流程服务的发布，往往也伴随着服务的寻找(或者说发现）流程。这里的服务的寻找流程主要是为了催促能提供服务的一方，尽快提供服务;在someip协议中规定使用find报文来表示。

有了上述的服务寻找与发现流程后，就可以method通信。

1.Client端需要某个服务，那么就可以通过find报文广播出去;Client一般不知道服务到底是谁能提供，所以广发英雄帖（组播），谁能提供服务Client不需要关心(该部分由SD管理)。
2.Server端收到了需要服务的英雄帖后，对比一下自己是否能提供该服务:如果自己提供不了，就忽略该find报文;如果自己能提供，便发出ofer报文，告诉Client有该服务(该部分由SD管理)。这里的Offer同时还会携带自己业务服务所在的IP和port地址，以便Client能知道去哪里请求服务。
3.Client端收到ofer报文后，就知道Server在提供自己需要的服务了;就可以按照自己的需求去请求该服务了(即Request、Response流程)。这里补充一点:在实际代码实现中，Client在收到Offer后，会由Client SD先通知Client，Client才会启动去Request。否者Client没有收到Offer，也不知道去哪个地址请求服务。如果是TCP通信，在Client SD通知Client后，会由Client发起TCP三次握手建链。
服务发布与Method通信
在这里插入图片描述
半周期回复Offer：
半周期回复Offer设定:在周期发送offer阶段中，如果是1/2周期前收到的find，会回复一条单播的offer;如果是1/2周期后收到find ,会回复一条组播的offer。这里回复单播就是单独告诉发送find的Client端;而发送组播，是为了节约网络带宽。

stop offer 主动停止服务。

2.2.2、服务订阅与Event通信：

下面开始，就是服务订阅的内容。服务的订阅也需要服务发布流程，但是多了订阅的步骤，服务的订阅流程服务的订阅由client SD在收到Ofer确认有人能提供服务后主动发起。
someip中规定服务的订阅需要两步，subscribe报文和subscribe ack报文。
与Method流程相同的是在TCP建链及之前的部分，Client的SD主动发起订阅，Server的SD收到订阅后，通知业务服务，可以发送event了，然后Server的SD立即回复一个ACK消息，让Client业务做好接收的准备。然后Server根据自身需要开始发送event。

服务订阅与Event通信
在这里插入图片描述
多个client订阅一个server的服务是否可以使用组播方式？
订阅服务的组播、单播：
threshold：指定何时使用多播以及何时使用单播发送通知事件。此值必须设置为非负数。如果设置为零，则eventgroup的所有事件将通过单播发送。否则，只要订阅数低于阈值事件将通过单播发送，如果订阅数大于或等于阈值，将多播发送。这意味着，阈值为1将导致所有事件正在通过多播发送。默认值为0。
Subscribe也有相应的stop机制：
Subscribe也有相应的stop机制，也可以发送Stop Subscribe和超时。作用就是停止订阅，让服务端不再给取消订阅的client发送event。
一个服务上线了不代表event就准备好了，如果event没有准备好，就有人来订阅了，那么会回复subscribe nack。

2.2.3、SD保活作用：

offer的作用：告诉大家当前的服务可用，有效时间TTL(TTL时间之后不可用)。
那么要让服务一直可用就要在TTL之前一直发送offer，来保持这个server的服务对这个client一直有效。
在这里插入图片描述
收到offer就会发送Subscribe

3、SD 状态机概述：

可以分为2个大状态: Down状态和Ready;而Ready又由3个子状态构成。所以也可以分为4个小状态: Down Phase，（服务下线阶段)，Initial Wait Phase(初始等待阶段)，Repettion Phase(重复阶段)和Main Phase(主阶段)。Ready状态里的所有子状态内都会含有一个计时器，大多数情况会定时进入下一个阶段。当进入到Main Phase后，除非服务主动下线，否者一般不会再退出。
服务的Down状态表示服务不可用或未注册。服务进入Down状态通常有以下两种情况：
服务未注册：当服务未成功注册时，服务的状态会被设置为Down。未注册的服务无法被客户端访问。
服务异常：当服务在运行过程中出现异常，例如网络连接中断、服务崩溃等，服务的状态也会被设置为Down。在此情况下，服务会被认为是不可用的，并将从服务列表中移除，直到服务重新注册。

3.1、server SD ：

在这里插入图片描述
上电初始化：
如果上电后通信不通或者服务没有上线，那么之后就不用发offer等信息，就进入到Not Ready状态待命，当状态机在Not Ready中时，如果这时检测到通信状态发生改变或者服务状态发生改变，那么就尝试去判断通信是否通了且服务是否上线if((status=-up_and_configured) and (service-statusup))。如果上述条件都满足，那么状态机会从Not Ready切换到Ready。
反之，如果statusup_and_configured和service-status==up.不满足任意一个条件，那么就要从Ready状态机回到Not Ready状态

3.2、client SD 状态机：

在这里插入图片描述
服务端与client区别：
Client状态机与Server状态机最大的不同就是一旦收到Offer后，会直接进入Main阶段。另一个区别是Server在Main中会不断周期发送Offer;但是Client在Main中不需要发送Find(因为Find的作用的触发激活Server上线，对端不上线的话，不断触发没有太大意义，也浪费总线带宽;而Offer的作用是保活，是要不断发送才能刷新TTL)。这也是为啥Client为什么一收到offer后，就不会再发送Find了。

每个服务都有一个SD状态机，用于处理服务的SD过程。服务的SD状态机包括多个状态，服务在不同的状态之间进行状态转换，以完成服务的SD过程。
someip/SD参数：
“service-discovery” :
{
“enable” : “true”,
“multicast” : “224.244.224.245”, //用于someipSD的多播地址
“port” : “30490”, //服务发现的端口
“protocol” : “udp”, //协议选择
“initial_delay_min” : “10”, //第一次提供信息前的最小延迟
“initial_delay_max” : “10000”, //首次提供信息前的最大延迟
“repetitions_base_delay” : “20”, //在重复阶段发送消息的基本延迟
“repetitions_max” : “5”, //在重复阶段的服务范围内提供服务的最大重复次数
“ttl” : “30”, //提供的服务以及已使用的服务和事件组的条目的生存期
“cyclic_offer_delay” : “200”, //主阶段中OfferService消息的周期
“request_response_delay” : “1500” //单播消息到多播消息的最小延迟
}