SOME/IP-SD 深入浅出

上一篇文章中，我们了解了一条完整的SOME/IP报文应该长什么样子，但这显然是不够的，至少还有以下这几个问题并没有得到明确的解决：

• Client如何发现服务

• 当服务不可用时，如何通知Client

• Client如何订阅事件

这些就是SOME/IP-SD要做的事情了。SOME/IP-SD也是基于SOME/IP的报文，用来实现服务发现和事件订阅机制。SOME/IP-SD消息通过UDP进行传输，报文格式如下图所示：

Flags=重新启动标志+单播标志+显示初始数据控制标志，如下图所示：

服务重新启动后，所有消息的Reboot Flag须置为1，直到Session ID重新从1开始计数，之后的Reboot Flag须置为0。

Entries Array，Entry可以理解为“入口”，包含了服务实例以及需要订阅的事件组的信息，分为Service和Eventgroup两种类型，一个SD报文可能包含多个Entry，每个Entry大小都是16个字节，一个Entry可能包含0-2个Option。下图为一个完整的SD报文示例：

Service Entry 用于服务发现：

• Type：当网络中未收到相关服务的OfferService或者暂时未收到，而Client又需要访问该服务，那Client可以发出FindService去主动寻找服务，如果Service已经就绪的话，会回复OfferService报文；服务就绪后，主动发出OfferService，用以告知组播内其他节点，该服务已经启动，可以创建连接；当服务不可用时，会主动发送StopOfferService报文，用以告知组播内其他节点，该服务目前不可用，停止发送请求，并取消订阅。

Type值	名称
0x00	FindService
0x01	OfferService
	StopOfferService

• Index 1st options：Option1排在Array里第几个

• Index 2nd options：Option2排在Array里第几个

• # of opt 1：Option1的数目

• # of opt 2：Option2的数目

• Service ID：Entry关于哪个服务

• Instance ID：Entry关于服务的哪个实例，0xFFFF表示全部实例

• Major Version：服务的主版本号

• TTL：“入口”的生命周期，单位为秒，我理解为发现服务时的搜索时间，提供服务时的有效时间

• Minor Version：服务的次版本号

服务发现，说白了，就是想办法让服务消费者能够找到服务提供者。打个比方，想象你在一个有很多人的广场上找一个会唱歌的人，很显然有两种情况：1. 你认识这个人，提前说好了，他站在某个地方等你，而你知道那个地方的位置，那你肯定很容易就找到他了，这就是静态配置；2. 你并不认识这个人，存在一个中间人，你告诉中间人你想找一个会唱歌的，而那个人也会告诉中间人我是会唱歌的，我站在广场的哪个位置，然后中间人把位置给你，你就可以找到他了，这就是动态发现，而SOME/IP-SD就是那个中间人。

Eventgroup Entry 用于事件订阅：

• Type：当Client收到服务OfferService之后，Client可以发送Subscribe报文主动跟Service订阅感兴趣的事件组；当Client订阅某个事件组之后，后续发现不再需要改事件组的数据了，可以通过StopSubscribe报文来通知Service，避免不必要的数据交互；当Service收到Client的Subscribe报文之后，需要先行判断是否符合可订阅的条件，如果该Client满足事件组订阅条件，则返回SubscribeAck，告知Client订阅成功，当事件组内的事件准备就绪之后，Service会以某种约定好的形式发送相关事件给成功订阅的Client，如果该Client不符合事件组订阅条件，那Service就会直接回复SubscribeEventgroupNack，告知订阅失败。

Type值	名称
0x06	Subscribe
	StopSubscribeEventgroup
0x07	SubscribeAck
	SubscribeEventgroupNack

• Initial Data Requested Flag：如初始值由服务发送，须置为1

• Counter：区分相同订阅者的订阅请求

• Eventgroup ID：事件组ID，也就是说SOME/IP事件订阅和取消订阅的颗粒度到一个事件组，而不是一个事件

下面的示例，说明了一个Client发现服务和订阅事件组的过程：

Options Array，Option可以理解为选项参数，Type=0x01时，用于传输Entry的附加信息，比如服务名等等：

Type=0x04时，用于传输IPv4相关的参数，比如服务的IP地址、TCP还是UDP、端口号：

从下图可知，对于不同的消息，要配置的选项类型也不一样，甚至不需要配置，其他几种选项的具体内容不一一列举了，用到了查下官方文档就行了，关注公众号，回复“SOMEIP协议”，即可获得相关文档~

到这里，SOME/IP算介绍完了。是不是觉得如果要自己实现SOME/IP全部的协议，还是有点复杂的，目前GENIVI的vsomeip开源库已经实现了SOME/IP协议栈，所以通常并不用再去造轮子。换言之，我们完全可以基于vsomeip开发SOME/IP应用程序，不用关心报文长什么样，也不用关心服务发现和事件订阅的细节，拿到手已经是Payload了，如果再用上GENIVI的CommonAPI，IDL一写，一条命令下去，代码自动生成了，Payload都用不着解析了，这样就实现了真正的RPC，是不是有点感兴趣了呢，那就继续关注我吧～

才写了两篇技术文章，已经感觉被掏空，虽然都是之前比较熟悉的有所积累的东西，但是要有条理地输出成篇，也不是件简单的事。尽管没什么人看，还是希望能逐字逐句地力求准确地描述，最后，感谢您的耐心阅读，您的点赞+在看，价值百万～