前言
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可以使用不同的协议）