SOME/IP--协议英文原文讲解8

前言 SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

3. python/C++举例调试讲解

4.2 Specification of SOME/IP Protocol This chapter describes the Remote Procedure Call(RPC), Event Notifications and Error Handling of SOME/IP.

4.2.1 Transport Protocol Bindings In order to transport SOME/IP messages different transport protocols may be used. SOME/IP currently supports UDP and TCP. Their bindings are explained in the following sections, while Chapter 6 discusses which transport protocol to choose.

SOME/IP支持TCP/UDP传输 第6章讲怎么选择

[PRS_SOMEIP_00138] Upstream requirements: RS_SOMEIP_00015 If a server runs different instances of the same service, messages belonging to different service instances shall be mapped to the service instance by the transport protocol port on the server side. For details of see Chapter 4.2.1.3

不同的服务实例在不同的server上要用port区分

什么是 服务实例？

 服务 是给一组或一种功能 编的号码。如果多个设备同时都提供这个服务，那怎么区分呢？ 就在服务ID的基础上 再进一步区分实例ID，实例就是实现这个服务的不同设备。给这些设备编上不同ID，这个ID就是实例ID。

[PRS_SOMEIP_00535] Upstream requirements: RS_SOMEIP_00010 All Transport Protocol Bindings shall support transporting more than one SOME/IP message in a Transport Layer PDU (i.e. UDP packet or TCP segment). TCP UDP 都应支持SOME/IP的聚包发送 -- 单条UDP/TCP消息中有多条SOME/IP消息组合在一起 [PRS_SOMEIP_00142] Upstream requirements: RS_SOMEIP_00010 The receiving SOME/IP implementation shall be capable of receiving unaligned SOME/IP messages transported by UDP or TCP. 传输层过来的多条消息长度不同的SOMEIP消息 要能够拆分解析 Rationale: When transporting multiple SOME/IP payloads in UDP or TCP the alignment of the payloads can be only guaranteed, if the length of every payloads is a multiple of the alignment size (e.g. 32 bits).

[PRS_SOMEIP_00140] Upstream requirements: RS_SOMEIP_00010 The header format allows transporting more than one SOME/IP message in a single packet. The SOME/IP implementation shall identify the end of a SOME/IP message by means of the SOME/IP length field. Based on the packet length field, SOME/IP shall determine if there are additional SOME/IP messages in the packet. This shall apply for UDP and TCP transport. SOMEIP header的长度字段 就能解析和拆分多条消息。

[PRS_SOMEIP_00141] Upstream requirements: RS_SOMEIP_00010, RS_SOMEIP_00027 Each SOME/IP payload shall have its own SOME/IP header. 每个payload都对应 自己的 header

[PRS_SOMEIP_00940] Upstream requirements: RS_SOMEIP_00010, RS_SOMEIP_00027 One Service-Instance can use the following setup for its communication of all the methods, events, and notifications: • up to one TCP connection • up to one UDP unicast connection • up to one UDP multicast connection -- 只能用于events/notify 服务的方法、事件、通知功能 可以通过TCP UDP单播/多播 通信。不包含UDP广播 具体下面有讲，不能一概而论

4.2.1.1 UDP Binding [PRS_SOMEIP_00139] Upstream requirements: RS_SOMEIP_00010 The UDP binding of SOME/IP shall be achieved by transporting SOME/IP messages in UDP packets. [PRS_SOMEIP_00137] Upstream requirements: RS_SOMEIP_00010 SOME/IP protocol shall not restrict the usage of UDP fragmentation. 不能限制 UDP协议在IP层默认的分包功能

[PRS_SOMEIP_00943] Upstream requirements: RS_SOMEIP_00010 The client and server shall use a single UDP unicast connection for all methods, events, and notifications of a Service-Instance which are configured to be communicated using UDP unicast. 方法 事件 和 通知 都可以用单播 [PRS_SOMEIP_00942] Upstream requirements: RS_SOMEIP_00010 The client and server shall use a single UDP multicast address combination ("connection") per eventgroup, which is configured to be communicated using UDP multicast. 这个意思是每个事件组 只能绑定在一个组播地址上 ，但是多个事件组可以绑定在一个组播地址上

If the same multicast address is shared between different service instances of the same service, then the port number of the UDP multicast address combination used for each of these service instances shall be different, at least on server side. 同一个服务的不同实例对象共享同一个组播地址则需要用端口号做区分

4.2.1.2 TCP Binding The TCP binding of SOME/IP is heavily based on the UDP binding. In contrast to the UDP binding, the TCP binding allows much bigger SOME/IP messages and uses the robustness features of TCP (coping with loss, reorder, duplication, etc.). In order to lower latency and reaction time, Nagle’s algorithm should be turned off (TCP_NODELAY). 通过 setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int)) 关闭了 Nagle's Algorithm，参数 flag 设置为 1 以启用 TCP_NODELAY。防止TCP组包延迟 [PRS_SOMEIP_00706] Upstream requirements: RS_SOMEIP_00010 When the TCP connection is lost, pending requests shall be handled if a timeout occurred. 编程指导：当TCP连接断开时 则需要处理挤压的待发送的请求或回复 Since TCP handles reliability, additional means of reliability are not needed. TCP处理 不要SOMEIP层做额外的可靠性传输动作 [PRS_SOMEIP_00707] Upstream requirements: RS_SOMEIP_00010 The client and server shall use a single TCP connection for all methods, events, and notifications of a Service-Instance which are configured to be communicated using TCP. 一个server 一个client 之间的所有服务相关的方法事件通知 可以用一个tcp连接进行通信。

[PRS_SOMEIP_00708] Upstream requirements: RS_SOMEIP_00010 The TCP connection shall be opened by the client, when the first method call shall be transported or the client tries to receive the first notifications. tcp的连接 应该由 client端发起， 当client 第一次发起method获取 准备接收nofiy时 The client is responsible for re-establishing the TCP connection whenever it fails. 当TCP 连接断开时，client有义务重新发起连接 [PRS_SOMEIP_00709] Upstream requirements: RS_SOMEIP_00010 The TCP connection shall be closed by the client, when the TCP connection is not required anymore. TCP的断开 应该由client发起，当client不在需要时 或不能拥有时。 [PRS_SOMEIP_00710] Upstream requirements: RS_SOMEIP_00010 The TCP connection shall be closed by the client, when all Services using the TCP connections are not available anymore (stopped or timed out). server端发起stop offer 或 offer的TTL超时 ，应该由client发起断链

[PRS_SOMEIP_00711] Upstream requirements: RS_SOMEIP_00010 The server shall not stop the TCP connection when stopping all services. Give the client enough time to process the control data to shutdown the TCP connection itself. server发送stop offer后 应该留时间等待client断链 Rational: When the server closes the TCP connection before the client recognized that the TCP is not needed anymore, the client will try to reestablish the TCP connection. 就算server发起了断链，当client发现server服务继续有效时 应该继续发起连接

Allowing resync to TCP stream using Magic Cookies 下面 展示了server和client 发送Magic Cookies消息的固定格式和内容。 对方收到这个报文后不需要回复 这是一个边界消息。 比如TP消息（后面讲：UDP的SOME/IP分片功能） 发送最后一包后 这个可以用作进一步确认是最后一包。

[PRS_SOMEIP_00154] Upstream requirements: RS_SOMEIP_00010 In order to allow testing tools to identify the boundaries of SOME/IP Message transported via TCP, the SOME/IP Magic Cookie Message may be inserted into the SOME/IP messages over TCP message stream at regular distances. [PRS_SOMEIP_00160] Upstream requirements: RS_SOMEIP_00010 The layout of the Magic Cookie Messages shall consist of the followign fields: • for communincation from Client to Server: – Message ID (Service ID/Method ID): 0xFFFF 0000 – Length: 0x0000 0008 – Request ID (Client ID/Session ID): 0xDEAD BEEF – Protocol Version: 0x01 – Interface Version: 0x01 – Message Type: 0x01 – Return Code: 0x00

• for communincation from Server to Client: – Message ID (Service ID/Method ID): 0xFFFF 8000 – Length: 0x0000 0008 – Request ID (Client ID/Session ID): 0xDEAD BEEF – Protocol Version: 0x01 – Interface Version: 0x01 – Message Type: 0x02 – Return Code: 0x00

4.2.1.3 Multiple Service-Instances [PRS_SOMEIP_00162] Upstream requirements: RS_SOMEIP_00015 Service-Instances of the same Service are identified through different Instance IDs. It shall be supported that multiple Service-Instances reside on different ECUs as well as multiple Service-Instances of one or more Services reside on one single ECU. 不同的实例 应该有不同的实例ID。 多个实例 可以部署在不同的ECU 或 单个ECU上 [PRS_SOMEIP_00163] Upstream requirements: RS_SOMEIP_00015 While several Service-Instances of different Services shall be able to share the same port number of the transport layer protocol used on both the provided/server and the consumed/client side, multiple Service-Instances of the same Service on the provided/server side on one single ECU shall use different port numbers per ServiceInstance. Multiple Service-Instances of the same Service on the required/client side on one single ECU may use the same port number per Service-Instance. 1. 不同服务的多个实例 可以使用同一个port(不管是client还是server) 2. server端 单个服务的多个实例 要用不同的Port区分 3. client端 单个服务的多个实例可以使用一个port

Rationale: Normal SOME/IP (not SOME/IP-SD) messages do not carry the ServiceInstance ID as a dedicated field in the SOME/IP header. - Thus port numbers (and perhaps the transport protocol) need to be used to distinguish different Service-Instance of the same Service of a single ECU. This way a Service-Instance can be identified through the combination of the Service ID combined with the endpoint information (i.e., IP-address, transport protocol (UDP/TCP), and port number). It is sufficient to use different port numbers for the different Service-Instances of the same Service on either the server or the client side, since only a single difference in the 4-tuple <src IP, src port, dst IP, dst port > is sufficient as a distinguishing criterion. As the server is the one actually providing the different Service-Instances, the server is also the natural place to handle the distinction. = > The server shall use different port numbers for providing different Service-Instances of the same Service. 不同的实例 肯定处于不同的TCP/UDP连接中，否则区分实例就没意义了。

不同的连接 就要依赖四元组来区分。 由于 client端 IP+prot 同一组可以接收不同实例的数据，就不能用client的IP和port来区分实例连接。 另外同一个ECU（IP)也可以有不同的实例，那就只能通过server的prt来区分不同的实例了。

Recommendation: It is recommended that instances use the same port number for UDP and TCP. If a Service-Instance uses UDP port x, only this Service-Instance of the Service and not another Service-Instance of the same Service should use exactly TCP port x for its Service provision. 建议：对于同一个服务的同一个实例 server端或client端的UDP和TCP协议可以用同一个端口号。（同一个服务 不同event/method可以使用不同的协议）