当服务不可用时SOME/IP-SD是如何通知Client的呢?

电子说

1.3w人已加入

描述

SOME/IP-SD也是基于SOME/IP的报文,用来实现服务发现和事件订阅机制。SOME/IP-SD消息通过UDP进行传输,报文格式如下图所示:

UDP协议

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

UDP协议

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

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

UDP协议

UDP协议

Service Entry 用于服务发现:

UDP协议

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

UDP协议

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:服务的次版本号

服务发现,说白了,就是想办法让服务消费者能够找到服务提供者。打个比方,想象你在一个有很多人的广场上找一个会唱歌的人,很显然有两种情况:

你认识这个人,提前说好了,他站在某个地方等你,而你知道那个地方的位置,那你肯定很容易就找到他了,这就是静态配置;

你并不认识这个人,存在一个中间人,你告诉中间人你想找一个会唱歌的,而那个人也会告诉中间人我是会唱歌的,我站在广场的哪个位置,然后中间人把位置给你,你就可以找到他了,这就是动态发现,而SOME/IP-SD就是那个中间人。

Eventgroup Entry 用于事件订阅:

UDP协议

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

UDP协议

Initial Data Requested Flag:如初始值由服务发送,须置为1

Counter:区分相同订阅者的订阅请求

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

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

UDP协议

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

UDP协议

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

UDP协议

从下图可知,对于不同的消息,要配置的选项类型也不一样,甚至不需要配置,其他几种选项的具体内容不一一列举了

UDP协议

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

审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分