车载以太网学习（SOME/IP学习笔记二）

SOME/IP-SD数据的格式：特殊的SOME/IP数据格式，对SOME/IP的payload的延申

 

        1、Flags=重新启动标志+单播标志+显示初始数据控制标志

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

        a、Service:find offer service / offer service / stop offer sercive

        b、Eventgroup:subscribe 

        例子：OfferService entry

 

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

        Index 2nt options: Option2排在Array里第几个

        I# of opt 1: Option1的数目

        I# of opt 2: Option2的数目

        Service ID：服务ID应设置为所提供服务实例的服务ID。

        Instance ID：实例ID应设置为提供的服务实例的实例ID。

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

        

 

        Major Version：主要版本设置为0xFF，这意味着应返回任何版本的服务。如果设置为不同于0xFF的值，则至于具有此特定主版本的服务被返回。由于SdServerServiceMajorVersion最大只能是0xFE的值，因此在OfferService Entry中不能出现值0xFF。

        Minor Version：次要版本设置为所提供服务实例的次要版本。

        TTL：应根据配置进行设置。如果TTL设置为0xFFFFFF，则SubscribeEventgroup条目应被视为有效，直至关闭（即下次重新启动）。如果TTL设置为0xFFFFFF，则OfferService条目应被视为有效，直到下一次重启。

        OfferService条目应始终引用至少一个IPv4或IPv6 Endpoint Option ，以表明服务如何得到。

        对于服务所需的每个L4协议（即UDP和/或TCP），如果支持IPv6，则应添加IPv6端点选项。

        端点选项的IP地址和端口号也应该用于传送事件和通知事件。

        对于UDP，此信息用于事件和通知事件的源地址和源端口。

        在TCP的情况下，这些IP地址和端口是客户端所需要的，用来建立TCP连接以接收Event。

        例子：FindService entry

        

        Service ID：服务ID应设置为应找到的服务的Service ID。

        Instance ID：如果返回所有服务实例，则实例ID应设置为0xFFFF。

        Major Version：主要版本应设置为0xFF，这意味着应返回任何版本的服务。如果设置为不同于0xFF的值，则至于具有此特定主版本的服务被返回。

        Minor Version：次要版本应设置为0xFFFF FFFF，这意味着应返回任何版本的服务。如果设置为不同于0xFFFF FFFF的值，则仅返回具有此特定次要版本的服务。

         TTL：应根据配置进行设置。如果TTL设置为0xFFFFFF，则SubscribeEventgroup条目应被视为有效，直至关闭（即下次重新启动）

如果配置如此，FindServer条目不得引用Endpoint或Multicast option。他们应引用configuration options 。

SOME/IP-SD 的示例如下所示

3、Options Array

        Option数组是服务发现消息的最后一部分。 选项数组中的选项带有附加信息。

4、服务端的通信行为

 

 

• Down Phase
  • 在这个阶段，Service是不可用的，即服务端无法提供服务

• Initial Wait Phase
  • 当服务准备完毕(Available)后，进入此阶段
  • 如果此阶段收到Find Service报文，服务端忽略此消息，不做任何处理
  • 如果服务不可用了，将返回进入Down Phase
  • 此阶段需要定义时间参数INITIAL_DELAY_Min和INITIAL_DELAY_Max，初始化时间取其之间的随机值，当定时器超时后，发送第一帧OfferService，标志着进入下一个阶段

• Repetition Phase
  • 为了让客户端快速找到有哪些Service，此阶段重复发送OfferService，重复次数由REPETITIONS_MAX决定
  • 发送间隔以REPETITIONS_BASE_DELAY为基本时间，每发送一次，间隔是前一间隔的2倍
  • 如果收到某客户端的FindService，不影响当前阶段的发送计数和计时，延迟一定时间(REQUEST_RESPONSE_DELAY)后，单独发送单播OfferService给服务请求端
  • 如果收到SubscribeEventgroup后，发送单播Ack/Nack，启动此订阅Entry的TTL计时器
  • 如果收到StopSubscribeEventgroup后，停止此订阅Entry的TTL计时器
  • 如果服务不可用，离开此阶段进入Down Phase，并发送StopOfferService通知所有客户端

• Main Phase
  • 此阶段将周期性发送OfferService，周期时间为CYCLIC_OFFER_DELAY
  • 如果收到某客户端的FindService，不影响发送计数，延迟一定时间(REQUEST_RESPONSE_DELAY)后，发送单播OfferService给服务请求端
  • 如果收到SubscribeEventgroup后，发送单播Ack/Nack，启动此订阅Entry的TTL计时器
  • 收到StopSubscribeEventgroup后，停止此订阅Entry的TTL计时器
  • 如果服务不可用，离开此阶段进入Down Phase，并发送StopOfferService

5、客户端的通信行为：

• Down Phase
  • 服务未被应用请求
  • 收到OfferService，存储当前服务实例状态，启动TTL计时器，此时服务若被应用请求，直接进入Main Phase
• Initial Wait Phase
  • 服务被请求后，进入此阶段
  • 等待INITIAL_DELAY时间（最大和最小值之间的随机值）
  • 如果此时收到Offer Service，则取消计时器，直接进入Main Phase
  • 如果服务请求被释放，进入Down Phase
  • 计时器超时后，发送第一个Find service，进入下一阶段

   

• Repetition Phase
  • 重复发送Find service，重复次数由REPETITIONS_MAX决定
  • 发送间隔以REPETITIONS_BASE_DELAY为基时间，每发送一次，间隔加倍
  • 收到Offer Service，停止发送计数和计时，立即进入Main Phase；触发发送SubscribeEventgroup(延迟一定时间）
  • 如果服务请求被释放，进入Down Phase；若有订阅，则发送StopSubscribeEventgroup

• Main Phase
  • 不再周期发送Find Service
  • 收到Offer Service，触发发送SubscribeEventgroup(延迟一定时间）
  • 如果收到StopOfferService，则停止所有计时器
  • 如果服务请求被释放，进入Down Phase；若有订阅，则发送StopSubscribeEventgroup