SOME/IP学习笔记

什么是SOME/IP?

SOME/IP概述

SOME/IP的全称是:Scalable Service-Oriented Middleware over IP。
字面理解:基于IP协议可拓展的面向服务的中间件。
概述:SOME/IP是一种汽车中间件解决方案,可用于控制消息。它为完美地适应不同尺寸和不同操作系统的设备而被设计。包括小型设备,如相机、AUTOSAR设备,以及音响主机或远程信息处理设备。它还确保SOME/IP支持信息娱乐域以及车辆中其他域的功能,允许SOME/IP用于大多数替换场景以及更传统的CAN场景。SOME/IP在以太网协议架构中位于第五层应用层,用于通信控制和服务发现。

SOME/IP缩略语

缩略语 描述
Client-Service-Instance-Entry 另一个ECU提供的服务实例的配置和所需数据在使用该服务(客户端)的ECU中应称为“客户端服务实例条目”
Field 字段代表一种状态,因此始终具有有效值,getter、setter和notfier都会对其执行操作
Finding a service instance 发送SOME/IP-SD消息以查找所需的服务实例
Getter 允许对字段进行读取访问的请求/响应调用
Method 被调用的方法、过程、功能或子例程
Notifier 当字段值发生变化时,发送带有新值的事件消息
Request 客户端发送给服务器调用方法的消息
Response 服务器发送给客户端的消息,传输方法调用的结果
SD 服务发现
Service 零个或多个方法、零个或多个事件以及零个或多个字段的逻辑组合(允许空服务,例如用于在SOME/IP-SD中宣布非SOME/IP服务)
Service Instance 服务接口的软件实现,可以在车辆中多次存在,也可以在ECU上多次存在
Service Interface 服务的正式规范,包括其方法、事件和字段
Setter 允许对字段进行写访问的请求/响应调用
SOME/IP 基于IP的可扩展的面向服务的中间件

SOME/IP的技术细节

序列化

SOME/IP序列化是为了高效而设计的。即,它使用最少的RAM和CPU资源,通过使用二进制和非描述性格式实现。消息的格式和消息在内存中的表现形式(打包结构)非常相似甚至完全一样。
SOME/IP可以序列化以下基本数据类型(数据类型默认以网络字节顺序/大端序编码,但也可以以小端序编码):
*布尔值:一个8位字段,编码False(0)或True(1)。不允许使用所有其他值。

  • uint8:8位大小的无符号整数。
  • uint16:16位大小的无符号整数。
  • uint32:32位大小的无符号整数。
  • uint64:64位大小的无符号整数。
  • sint8:8位大小的有符号整数。
  • sint16:16位大小的有符号整数。
  • sint32:32位大小的有符号整数。
  • sint64:64位大小的有符号整数。
  • float32:32位大小的浮点数。
  • float64:64位大小的浮点数。

SOME/IP可以序列化以下复杂数据类型:

  • struct:组合了预定义参数列表的参数。结构可以以可选的长度字段开头,对长度字段后面的结构的所有字节进行计数。
  • string:传输ascii、UTF-8或UTF-16字符的固定长度或动态长度字符串。对于动态长度字符串,字符串以大端编码长度字段开头,对字符串字符使用的字节进行计数。
  • array:包含相同参数类型的重复的参数。这可以是预定义数量或动态数量的参数。对于具有动态长度的数组,使用长度字段。
    enumeration:可以选择命名不同值的uint。
  • bitfield:8、16或32位参数,每个位代表一个布尔值。每个布尔值都可以有一个名称以及True和False值的名称。
  • union:可以携带预定义参数类型的参数的参数,该参数类型是在运行时确定的。序列化使用长度字段、类型字段和参数的数据。

长度和类型字段的大小为32位(默认),可配置为0、8、16或32位。所有长度和类型字段均以网络字节顺序/大端编码。

SOME/IP的RPC(远程过程调用)和messaging(消息传递)

SOME/IP服务支持以下消息:
请求/响应方法:从客户端发送到服务器的请求以及从服务器发回客户端的响应。此外,SOME/IP允许将错误响应而不是常规响应从服务器发送回客户端。此功能可用于在错误情况下实现不同的有效负载格式。
即发即忘方法:请求从客户端发送到服务器。
事件:事件从服务器发送到相关客户端。哪个客户端需要此事件将通过SOME/IP-SD确定。
字段:字段可以有一个选项通知器(要循环发送或更改时发送的事件)、一个可选的setter(更新字段的请求/响应方法)和一个可选的getter(用于读出字段的当前值的请求/响应方法)。
通信协议(拓展)
Remote Procedure Call(RPC)
远程过程调用(RPC)是一种软件通信协议,一个程序可以使用该协议向网络上另一台计算机上的程序请求服务,而无需了解网络的详细信息。RPC用于像本地系统一样调用远程系统上的其他进程。
在RPC期间,会发生以下步骤:

  • 客户端调用客户端存根。该调用是本地过程调用,参数以正常方式压入堆栈。
  • 客户端存根将过程参数打包到消息中,并进行系统调用来发送消息。过程参数的打包称为编组。
  • 客户端的本地操作系统将消息从客户端计算机发送到远程服务器计算机。
  • 服务器操作系统将传入数据包传递到服务器存根。
  • 服务器存根从消息中解包参数(称为解组) 。
  • 当服务器过程完成时,它返回到服务器存根,服务器存根将返回值封送到消息中。然后服务器存根将消息交给传输层。
  • 传输层将结果消息发送回客户端传输层,客户端传输层将消息传递回客户端存根。
  • 客户端存根解组返回参数,然后执行返回给调用者。

“Field message”(字段消息)(拓展)
"Field message"是一种在计算机科学和数据通信中常用的术语,通常指代在数据结构或通信协议中的一个特定字段所携带的信息。
在数据结构中,一个字段通常是数据的一个组成部分,它用于存储特定类型的数据。例如,在一个学生记录的数据结构中,可能包含学生的姓名、年龄和学号等字段。每个字段都携带了相应的信息。
在通信协议中,字段消息指的是在消息或数据包中的一个特定字段所承载的数据。这些字段可以包含有关通信的控制信息、标识符、参数值或其他类型的数据。字段消息的内容和格式在协议规范中定义,并且根据协议的要求进行解析和处理。
总之,“field message”(字段消息)是指在数据结构或通信协议中的一个特定字段所携带的信息。这些字段消息在数据交换和通信中起着重要的作用,用于传递和解释数据的含义和属性。

常见通信模式(拓展)

发布/订阅

发布/订阅是一种消息传递模式,其中消息的发送者(发布者)将消息发布到特定的主题或主题类别,而接收者(订阅者)通过订阅感兴趣的主题来接收消息。发布者和订阅者之间没有直接的依赖关系,发布者只需将消息发布到主题,而订阅者可以选择订阅一个或多个主题以接收相关消息。
在发布/订阅模式中,发布者和订阅者是解耦的,发布者无需关心具体的订阅者,而订阅者也不需要知道消息的来源。消息通过主题进行传递,发布者将消息发送到主题,而订阅者从感兴趣的主题中接收消息。
发布/订阅模式适用于广播消息、事件通知和实时数据流等场景。
一般都是先订阅,后发布。如果还没有用户订阅,那么也可以建立一个存放离线事件的堆栈。当事件发布的时候,如果此时还没有订阅者订阅这个事件,我们暂时把发布事件的动作包裹在一个函数里,这些包装函数会被存入堆栈中,等到有对象来订阅事件的时候,我们将遍历堆栈并依次执行这些包装函数,即重发里面的事件,不过离线事件的生命周期只有一次,就像qq未读消息只会提示你一次一样。

请求/响应

请求/响应是一种消息传递模式,其中消息的发送者(请求方)发送一个请求消息到接收者(响应方),接收者收到请求后进行处理,并返回相应的响应消息给请求方。这种模式涉及明确的请求和相应操作,其中请求方期望接收响应来获取结果或执行后续操作。
在请求/响应模式中,请求方和响应方之间是直接交互的。请求方发送请求消息,并等待接收响应消息。响应方接收请求消息,进行处理并生成响应消息,然后将响应消息发送回请求方。
请求/响应模式适用于需要同步操作和精确响应的场景。

点对点

在点对点模式中,消息发送者(发送方)将消息发送给一个具体的接收者(接收方),而不是将消息广播给多个订阅者。每个消息只有一个预定的接收者来处理。
这种模式适用于需要确保消息只有一个接收者处理的情况,或者需要进行一对一的交互和通信的场景。
点对点模式强调一对一通信,但和发送/响应不同,不期望得到响应。

SOME/IP功能规范

消息格式

SOME/IP Service discovery(服务发现)

背景和逻辑

服务发现模块的主要任务是管理车载通信中称为服务的功能实体的可用性以及控制事件消息的发送行为。这允许仅向需要它们的接收者发送事件消息(发布/订阅)。这里描述的解决方案也称为SOME/IP-SD(基于IP的可扩展的面向服务的中间件-服务发现)。
通过服务发现,不同的ECU(电子控制单元)可以提供服务实例并在车辆网络中查找可用的服务实例。ECU可以停止提供它之前提供的服务实例。之后的这样的服务实例的查找将持续没有回应。服务实例是由其服务接口定义的服务的单个实现。在AUTOSAR环境中,查找是识别可用服务实例及其位置的操作。
除了服务实例的状态之外,服务发现还能够控制发送称为事件的特殊消息。这些事件被分组为事件组,服务发现可以以发布/订阅的方式打开/关闭这些事件组;如此,打开/关闭该事件组的事件的发送和接收。
本地ECU需要处理两种不同类型的服务:

  • 服务器服务-本地ECU向车辆的其余部分提供服务器服务实例(即位于本地),并且可以被视为该服务实例的服务器。
  • 客户端服务-本地ECU可以使用车辆内另一个ECU提供的服务器服务实例,并且可以被视为该服务实例的客户端。

对于服务端接口,本地的ECUs的服务发现模块必须(服务角色):

  • 提供本地服务,当它可用时。例如,软件组件提供的服务已经就绪并且ECU当前的状态下的服务可用。
  • 如果服务不可用了,收回本地服务的提供(停止提供)
  • 回答和回复其他ECUs的发现(表示可被发现)

对于客户端接口,本地的ECUs的服务发现模块必须(客户角色):

  • 监听提供和发现,根据在易失性存储器中存储这些信息的配置
  • 监听提供停止,根据在易失性存储器中存储这些信息的配置
  • 依靠当前的ECU和它的软件组件发送发现(用于发现的报文,search)

服务发现也可以用来管理发布/订阅关系。在基于服务发现的发布/订阅用例中,一个ECU(使用ConsumedEventgroup(消费的事件组)的发布/订阅客户端)有兴趣从另一个ECU(使用EventHandler(事件处理程序)的发布/订阅服务器)接收一些数据(订阅)。

虽然订阅是在SD消息中明确定义的,但是发布是基于服务实例本身的可用性(OfferService条目)。根据所提供的服务实例,发布/订阅客户端可以通过SubscribeEventgroup条目进行订阅。发布/订阅服务器现在将使用该订阅将发布/订阅客户端注册为订阅指定的某些信息的相关方,并在某些事件或超时之前开始将该信息发送给发布/订阅客户端。

作为优化,SD支持使用多播消息向多个客户端发送事件消息,而不是每个客户端发送一个单播消息。请注意,它必须区分可在服务器端预配置的多播端点和可在客户端预配置的多播端点:

  1. 如果一个SdServerService在每个Eventhandler上有一个预配置的多播地址和端口,那么如果已订阅的具有不同端点信息的SdClientService已经达到了阈值(SdEventHandlerMulticastThreshold),则SdServerService将切换到这个多播地址和端口(所谓"Eventhandler多播端点")
  2. 如果SdClientService具有多播地址和端口(所谓"消费事件组多播端点"),则SdServerService在订阅时将其事件发送到消费事件组多播端点(多播地址和端口)。

要求

基本要求(部分)

[SWS_Sd_00005] 服务发现模块应存储ServiceModeRequest,该请求是通过BswM通过调用以下API提供的:

  • 分别为Sd_ServerServiceSetState()和Sd_ClientServiceSetState(),如果 SdServerService和SdClientSerivce分别未引用一个SdServiceGroup。
  • Sd_ServiceGroupStart和SdServiceGroupStop,如果 SdServerService和SdClientService分别引用一个SdServiceGroup。
  • Sd_ConsumedEventGroupSetState(),如果SdClientService 请求专用SdEventGroupS。(注意:允许此API调用独立于一个SdClientService对SdServiceGroup的引用)
  • Sd_EventHandlerSetState()当前不存在,因为该状态是通过服务发现直接从服务器服务的状态推导出来的。

注意:基于与SWC的交互,以下模式可以被BswM模块请求:

服务端SWC分别通过Sd_ServerServiceSetState()或Sd_ServiceGroupStart()和Sd_ ServiceGroupStop():

  • SD_SERVER_SERVICE_DOWN
  • SD_SERVER_SERVICE_AVAILABLE
    客户端SWC分别通过Sd_ClientServiceSetState()或Sd_ServiceGroupStart()和Sd_ServiceGroupStop():
  • SD_CLIENT_SERVICE_RELEASED
  • SD_CLIENT_SERVICE_REQUESTED
    客户端SWC通过Sd_ConsumedEventGroupSetState()
  • SD_CONSUMED_EVENTGROUP_RELEASED
  • SD_CONSUMED_EVENTGROUP_REQUESTED

"SD_SERVER_SERVICE_DOWN"表明提供此服务实例的本地SWC尚未准备好进行通信,
"SD_SERVER_SERVICE_AVAILABLE"表明提供此服务实例的本地SWC已准备好进行通信,
"SD_CLIENT_SERVICE_RELEASED"表明使用此服务实例的本地SWC不需要与此服务实例通信,
"SD_CLIENT_SERVICE_REQUESTED"表明使用此服务的本地SWC已准备好与此服务实例通信并且需要此服务实例,
"SD_CONSUMED_EVENTGROUP_RELEASED"表明使用此消费事件组的本地SWC不需要此消费事件组的事件,
"SD_CONSUMED_EVENTGROUP_REQUESTED"表明使用此消费事件组的本地SWC需要此消费事件组的事件。

[SWS_Sd_00007] 以下CurrentStates应可分别通过BswM_Sd_ClientServiceCurrentState()、BswM_Sd_ConsumedEventGroupCurrentState()和BswM_Sd_EventHandlerCurrentState()报告给BswM模块:

  • SD_CLIENT_SERVICE_DOWN
  • SD_CLIENT_SERVICE_AVAILABLE
  • SD_CONSUMED_EVENTGROUP_DOWN
  • SD_CONSUMED_EVENTGROUP_AVAILABLE
  • SD_EVENT_HANDLER_RELEASED
  • SD_EVENT_HANDLER_REQUESTED

"SD_CLIENT_SERVICE_DOWN"告诉本地SWC该服务实例不可用,
"SD_CLIENT_SERVICE_AVAILABLE"告诉本地SWC该服务实例可用,
"SD_CONSUMED_EVENTGROUP_DOWN"告诉本地SWC该消费事件组当前尚未订阅,
"SD_CONSUMED_EVENTGROUP_AVAILABLE"告诉本地SWC该消费事件组当前已被订阅(即接收到事件),
"SD_EVENT_HANDLER_RELEASED"告诉本地SWC当前没有客户端订阅此事件组,
"SD_EVENT_HANDLER_REQUESTED"告诉本地SWC当前至少有一个客户端订阅了该事件组。

以太网通信

[SWS_Sd_00013] 每个服务发现配置实例(参见配置容器SdInstance)应至少具有一个TxPdu ID、一个单播RxPdu ID和一个多播RxPdu ID(分别参见配置参数SdInstanceTxPdu、SdInstanceUnicastRxPdu和 SdInstanceMulticastRxPdu)。
TxPdu(Transmission Protocol Data Unit)它是计算机网络中用于传输的数据单元,通常用于描述在通信过程中发送的数据的格式和结构。
RxPdu(Reception Protocol Data Unit)表示在通信过程中接收到的数据单元。
[SWS_Sd_00017] 对于不同的链路,应配置单独的服务发现实例容器。
注意:
这里的链路还包括使用以太网VLANs的不同虚拟链路。
VLAN(Virtual Local Area Network)是一种虚拟局域网技术,用于在物理网络基础上划分逻辑上的独立网络。
[SWS_Sd_00697] SD实例仅支持单个地址系列(即IPv4或IPv6)。该地址族应通过SdInstanceTxPdu、SdInstanceUnicastRxPdu和 SdInstanceMulticastRxPdu(本地地址)的SoAd(socket adaptor)配置来获知。
[SWS_Sd_00723] 在SD模块初始化期间,应为与SdInstanceTxPdu、SdInstanceUnicastRxPdu和 SdInstanceMulticastRxPdu关联的所有套接字连接调用接口SoAd_OpenSoCon()
注意:SoAd 模块需要在 SD 模块初始化之前初始化。
注意:实现者必须通过验证服务发现和套接字适配器的源代码和配置来保证SoAd_SetUniqueRemoteAddr()、SoAd_GetLocalAddr()和SoAd_SetRemoteAddr()永远不会返回错误。 SoAd_SetUniqueRemoteAddr()、SoAd_GetLocalAddr()和SoAd_SetRemoteAddr()的失败无法恢复。

状态处理

[SWS_Sd_00019] 服务发现模块应单独存储所有静态配置的服务实例和事件组的状态。
[SWS_Sd_00020] 通过调用接口Sd_Init()初始化服务发现模块后,所有配置的服务器服务实例应具有状态"SD_SERVER_SERVICE_DOWN",除非服务器服务实例将SdServerService AutoAvailable设置为true,则该状态应为设置为"SD_SERVER_SERVICE_AVAILABLE"。
注意:SdClientServiceAutoRequire设置为true,仅适用于未引用SdServiceGroup的客户端服务。

[SWS_Sd_00440] 通过调用接口Sd_Init()初始化服务发现模块后,所有配置的事件组应具有状态"SD_CONSUMED_EVENTGROUP_RELEASED",除非消费事件组将“SdConsumedEventGroupAutoRequired”设置为true,则状态应为一旦请求关联的客户端服务实例,就设置为"SD_CONSUMED_EVENTGROUP_REQUESTED"。
[SWS_Sd_00402] 服务发现模块应存储服务器和客户端服务实例引用的所有IP地址分配状态。
[SWS_Sd_00442] 如果使用SD_CONSUMED_EVENTGROUP_REQUESTED 调用Sd_ConsumedEventGroupSetState,而其客户端服务实例仍处于释放状态(SD_CLIENT_SERVICE_RELEASED),则应返回E_NO_OK。
[SWS_Sd_00443] 如果SdClientService设置为SD_CLIENT_SERVICE_RELEASED(通过Sd_ClientServiceSetState()或Sd_ServiceGroupStop()),同时一项或多项它的事件组仍被请求(SD_CONSUMED_EVENTGROUP_REQUESTED)服务发现应先以与使用SD_CONSUMED_EVENTGROUP_RELEASED调用这些事件组相同的方式解释这一点。

与套接字适配器的交互

[SWS_Sd_00024] 服务发现模块应能够使用接口SoAd_EnableRouting()、SoAd_DisableRouting()、SoAd_EnableSpecificRouting()和SoAd_DisableSpecificRouting()为服务器和客户端服务实例启用/禁用SoAd模块内的路由组。
[SWS_Sd_00699] 服务发现模块应能够使用接口SoAd_IfSpecificRoutingGroupTransmit()触发初始事件的发送。
[SWS_Sd_00026] 服务发现模块应能够引用每个服务实例/事件组的路由组。请参见以下配置参数:略。
[SWS_Sd_00700] 服务发现模块应能够引用每个服务实例/事件组的套接字连接和套接字连接组。请参见以下配置参数:略。
[SWS_Sd_00029] 如果分配了IP地址,服务发现模块应仅调用 SoAd_IfTransmit();即:已使用当前状态TCPIP_IPADDR_STATE_ASSIGNED调用Sd_LocalIpAddrAssignmentChg()。
[SWS_Sd_00709] 如果SoAd_IfTransmit()返回E_NOT_OK,则忽略。
[SWS_Sd_00481] 如果满足以下所有条件,则应使用SoAd_ReleaseRemoteAddr()将每个通配符套接字连接重置为通配符:略

订阅事件组重试处理

订阅事件组重试机制是ClientServices的可选功能。如果SOME/IP-SD消息丢失(例如SubscribeEventGroupAck)并且周期提供之间的间隔太大而无法快速恢复,这可以用于加快恢复速度,或者如果在两者之间请求事件组,则可以加快订阅速度两个循环报价。订阅事件组重试机制的计时行为可以针对每个ClientService进行配置,并且必须与相应ServerService的计时行为相匹配(请参阅TPS SysT constr_5095)。对于将 TLL(SdServerTimerTTL)设置为0xFFFFFF且主阶段循环报价之间的间隔(SdServerTimerOfferCyclicDelay)设置为0的ServerService,可以将订阅事件组重试设置为0xFF(请参阅TPS SysT constr_5096)。这意味着当EventGroup设置为SD_CONSUMED_EVENTGROUP_REQUESTED并且未收到SubscribeEventGroup Ack时,将重试对EventGroup的订阅。

消息格式

[SWS_Sd_00037] 如果没有另外定义,服务发现消息中的所有字段均应采用网络字节顺序(即大端字节顺序)。

请求ID

本章描述与请求ID字段相关的要求。请求ID由客户端ID和会话ID组成。虽然客户端ID不用于服务发现,但会话ID用于检测车辆中其他服务发现实例的重新启动,以修复服务发现模块的本地状态。
[SWS_Sd_00034] 服务发现模块初始化后,本地ECU发送的消息的会话ID应为0x0001。
注意SWS_SD_00034:这意味着发出的第一条SD消息的会话ID设置为0x0001。根据PRS_SOMEIPSD_00160,服务发现模块必须处理每个通信伙伴的会话ID。因此,发送到多播端点的第一条SD消息以及发送到任何单播端点的第一条SD消息的会话ID设置为0x0001。

协议版本字段

协议版本字段用于描述SOME/IP的当前版本。

接口版本字段

Interface Version字段用于描述SOME/IP服务的当前版本;即 SOME/IP-SD本身的当前版本。

消息类型字段

消息类型字段用于区分SOME/IP消息的类型。SOME/IP-SD仅使用事件消息;因此,它总是使用相同的类型。

返回码字段

返回代码用于指示请求是否已成功处理。这不适用于SOME/IP-SD;因此,返回码将静态设置为0x00。

标志字段

SOME/IP-SD标头以标志字段开始。它用于发出全局服务发现信息,其中包括实时的上次重新启动的状态以及接收单播消息的能力。

[SWS_Sd_00448] 使用会话ID和重新启动标志检测到的重新启动将导致由该通信伙伴控制的本地状态到期。
如果客户端使用服务的服务器重新启动,客户端应像收到停止提供条目一样处理重新启动(另请参阅SWS_SD_00367了解更多详细信息)。
如果客户端使用服务的服务器重新启动,服务器应处理重新启动,就像收到StopSubscribeEventgroup条目一样(另请参阅SWS_SD_00345了解更多详细信息)。

保留字段

该保留字段当前未使用,留空以进一步增强SOME/IP-SD协议。

条目数组

当SOME/IP-SD查找或提供服务实例或处理订阅时,这是通过所谓的条目完成的,这些条目在SOME/IP-SD消息的条目数组中传输。

条目格式类型1

存在两种类型的条目:1.服务的类型,2.条目和事件组的类型。
第一种条目应该包含以下布局:

[SWS_Sd_00173] 类型1条目格式布局的服务ID字段应携带服务的服务ID,根据是服务器条目还是客户端条目,使用参数SdServerServiceID和SdClientServiceID进行静态配置。
[SWS_Sd_00175] 类型1条目格式布局的实例ID字段应携带服务的实例ID,根据是服务器条目还是客户端条目,使用参数SdServerServiceInstanceID和SdClientServiceInstanceID进行静态配置。
[SWS_Sd_00178] 类型1条目格式布局的主要版本字段应携带SdServerServiceMajorVersion和SdClientServiceMajorVersion,具体取决于服务器条目还是客户端条目。
[SWS_Sd_00180] 类型1条目格式布局的TTL字段定义使用参数SdServerTimerTTL和SdClientTimerTTL配置的服务器条目的生命周期(以秒为单位),Stop-Entries除外,其TTL为0。
注意:对于客户端,TTL值不用于类型1条目,并且应被服务器服务忽略。
[SWS_Sd_00182] 类型1条目格式布局的次要版本字段应携带SdServerServiceMinorVersion和SdClientServiceMinorVersion。

条目格式类型2

类型2条目格式应用于事件组。

[SWS_Sd_00193] 类型2条目格式布局的服务ID字段应携带事件组服务的服务ID,根据是服务器条目还是客户端条目,使用参数SdServerServiceID和SdClientServiceID进行静态配置。
[SWS_Sd_00195] 类型2条目格式布局的实例ID字段应携带使用参数SdServerServiceInstanceID和SdClientServiceInstanceID静态配置的事件组服务的实例ID,具体取决于服务器或客户端条目。
[SWS_Sd_00198] 类型2条目格式布局的主要版本字段应携带SdServerServiceMajorVersion和SdClientServiceMajorVersion,具体取决于服务器条目还是客户端条目。
[SWS_Sd_00200] 类型2条目格式布局的TTL字段定义使用参数SdServerTimerTTL和SdClientTimerTTL配置的条目的生命周期(以秒为单位),Stop或Nack-Entries除外,它们的TTL为0。
[SWS_Sd_00204] 类型2条目格式布局的事件组ID字段应携带事件组的ID,使用参数SdConsumedEvent GroupID配置。
[SWS_Sd_00476] 类型2条目(事件组条目)不得使用“任何值”作为服务ID(即0xFFFF)、实例ID(即0xFFFF)、事件组ID(即0xFFFF)和/或主要版本(即0xFF)。

选项数组

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

配置选项

配置选项传输服务发现消息中条目的附加属性。使用配置选项可以传输0到n个配置项。这些配置项可以包括例如主机或服务的名称。

略。