前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C++举例调试讲解
5.1.3.1 Eventgroup Entry 订阅、订阅回复、停止订阅Entry
sub/suback/subnack报文中 有显示订阅组 按组订阅的 不是具体eventID
具体eventID 在SOME/IP报文中有体现
5.1.3.1.1 Subscribe Eventgroup Entry 订阅事件组entry
[PRS_SOMEIPSD_00385]
Upstream requirements: RS_SOMEIPSD_00015
The Subscribe Eventgroup entry type shall be used to subscribe to an eventgroup.
Subscribe Eventgroup entry 用于订阅 事件组 -- 容易理解的陈述
[PRS_SOMEIPSD_00386]
Upstream requirements: RS_SOMEIPSD_00015
下面是订阅报文的entry格式。
Subscribe Eventgroup entries shall set the entry fields in the following way:
• Type shall be set to 0x06 (SubscribeEventgroup).
• Service ID shall be set to the Service ID of the service instance that includes the
eventgroup subscribed to.
• Instance ID shall be set to the Instance ID of the service instance that includes
the eventgroup subscribed to.
• Major Version shall be set to the Major Version of the service instance of the
eventgroup subscribed to.
• Eventgroup ID shall be set to the Eventgroup ID of the eventgroup subscribed to.
• TTL shall be set to the lifetime of the subscription.
– If set to 0xFFFFFF, the Subscribe Eventgroup entry shall be considered valid
until the next reboot.
– TTL shall not be set to 0x000000 since this is considered to be the Stop
Offer Service Entry.
• Reserved shall be set to 0x000 until further notice.
• Counter shall be used to differentiate between parallel subscribes to the same
eventgroup of the same service (only difference in endpoint). If not used, set to
0x0. Counter不太常用。其实通过客户端的的端点（IP+PORT）就可以区分客户端了，counter只是可以作为辅助
[PRS_SOMEIPSD_00846]
Upstream requirements: RS_SOMEIPSD_00015, RS_SOMEIPSD_00025
A SubscribeEventgroup entry reference the endpoints (IP address, port, and protocol)
where the client wishes to receive the events. A client service could subscribe to
the same Eventgroup either with a client unicast endpoint or with a client multicast
endpoint:
• If a client subscribes with a client unicast endpoint via an Endpoint Option, the
client announces its desire to receive the events as unicast events transmitted to
the given unicast endpoint.
• If a client subscribes with a client multicast endpoint via an Endpoint Option, the
client announces its desire to receive the events as multicast events transmitted
to the given multicast endpoint.
订阅entry对应的 endpoint - option 只能是单播 或 UDP组播。option中的IP-PORT是client自己的（希望server往这里发送的地址）
[PRS_SOMEIPSD_00387]
Upstream requirements: RS_SOMEIPSD_00015, RS_SOMEIPSD_00025
SubscribeEventgroup entries shall reference options according to the following rules:
• either up to two IPv4 or up to two IPv6 Endpoint Options (one for UDP, one for
TCP)
• either up to one IPv4 Multicast Option or up to one IPv6 Multicast Option (only
UDP supported)
Note:
This explicitly rules out that a single service instance is offered via IPv4 and IPv6 at the
same time.
### **1. 是否不能同时支持 IPv4 和 IPv6？**
是的，根据规范描述，**同一个服务实例不能同时通过 IPv4 和 IPv6 提供**。
#### 规范原文：
> This explicitly rules out that a single service instance is offered via IPv4 and IPv6 at the same time.
#### 解释：
- 在 `SubscribeEventgroup` 消息中，服务实例的端点选项（Endpoint Options）**只能选择 IPv4 或 IPv6**，而不能同时支持两者。
- 具体规则：
- 最多可以包含 **两个 IPv4 端点选项**（一个用于 UDP，一个用于 TCP）。
- 或者，最多可以包含 **两个 IPv6 端点选项**（一个用于 UDP，一个用于 TCP）。
#### 示例：
- **允许**：
- 两个 IPv4 端点选项（UDP 和 TCP）。
- 两个 IPv6 端点选项（UDP 和 TCP）。
- **不允许**：
- 一个 IPv4 端点选项和一个 IPv6 端点选项。
---
### **2. 是否可以同时支持 UDP 单播和 UDP 组播？**
是的，**可以同时支持 UDP 单播和 UDP 组播**。
#### 规范原文：
> either up to one IPv4 Multicast Option or up to one IPv6 Multicast Option (only UDP supported)
#### 解释：
- 在 `SubscribeEventgroup` 消息中，可以同时包含以下选项：
- **单播端点选项**（Unicast Endpoint Option）：
- 用于 UDP 单播通信。
- 例如：`IPv4 Endpoint Option` 或 `IPv6 Endpoint Option`。
- **组播端点选项**（Multicast Option）：
- 用于 UDP 组播通信。
- 例如：`IPv4 Multicast Option` 或 `IPv6 Multicast Option`。
- 需要注意的是：
- 组播选项 **仅支持 UDP**，不支持 TCP。
- 单播和组播选项的 IP 版本必须一致（即 IPv4 单播 + IPv4 组播，或 IPv6 单播 + IPv6 组播）。
#### 示例：
- **允许**：
- 一个 IPv4 单播端点选项（UDP） + 一个 IPv4 组播选项（UDP）。
- 一个 IPv6 单播端点选项（UDP） + 一个 IPv6 组播选项（UDP）。
- **不允许**：
- 一个 IPv4 单播端点选项（UDP） + 一个 IPv6 组播选项（UDP）。
---
### **3. 总结**
- **IPv4 和 IPv6**：
- 同一个服务实例 **不能同时支持 IPv4 和 IPv6**。
- 必须选择其中一种 IP 版本（IPv4 或 IPv6）。
- **UDP 单播和 UDP 组播**：
- 可以同时支持 **UDP 单播和 UDP 组播**。
- 单播和组播的 IP 版本必须一致（IPv4 或 IPv6）。
---
### **示例配置**
#### 示例 1：IPv4 单播 + IPv4 组播
- **单播**：
- `IPv4 Endpoint Option`（UDP）：`192.168.1.1:5000`
- **组播**：
- `IPv4 Multicast Option`（UDP）：`239.255.0.1:5001`
#### 示例 2：IPv6 单播 + IPv6 组播
- **单播**：
- `IPv6 Endpoint Option`（UDP）：`2001:db8::1:5000`
- **组播**：
- `IPv6 Multicast Option`（UDP）：`ff02::1:5001`
---
### **注意事项**
1. **IP 版本一致性**：
- 单播和组播选项的 IP 版本必须一致。
- 例如，不能混合使用 IPv4 单播和 IPv6 组播。
2. **TCP 不支持组播**：
- 组播选项 **仅支持 UDP**，TCP 不支持组播。
3. **端点选项数量限制**：
- 最多两个端点选项（单播 + 组播）。
- 例如，不能同时配置两个单播端点选项和一个组播端点选项。
---
[PRS_SOMEIPSD_00828]
Upstream requirements: RS_SOMEIPSD_00015, RS_SOMEIPSD_00025
When receiving a SubscribeEventgroup or StopSubscribeEventgroup the Service ID,
Instance ID, Eventgroup ID, and Major Version shall match exactly to the configured
values to identify an Eventgroup of a Service Instance.
当server收到 sub/stop sub报文时要 严格核对 Service ID,
Instance ID, Eventgroup ID, and Major Version 是否匹配
[PRS_SOMEIPSD_00810]
Upstream requirements: RS_SOMEIPSD_00015, RS_SOMEIPSD_00025
If the server receives a Subscribe Eventgroup entry without a UDP Endpoint Option
(see [PRS_SOMEIPSD_00387]) and the MULTICAST_THRESHOLD for the Eventgroup is not configured with value 1 then SubscribeEventGroupNack shall be sent
back to the client.
如果server 没有收到 udp单播的订阅（但是订阅的组又只支持UDP单播-- 客户矩阵表定义 并且MULTICAST_THRESHOLD!=1）则需要回复 sub nack报文
5.1.3.1.2 Stop Subscribe Eventgroup Entry 停止订阅事件组 entry
[PRS_SOMEIPSD_00388]
Upstream requirements: RS_SOMEIPSD_00017
The Stop Subscribe Eventgroup entry type shall be used to stop subscribing to eventgroups.
stop sub Eventgroup entry 类型报文用来 停止订阅事件组 -- 简单的陈述
[PRS_SOMEIPSD_00389]
Upstream requirements: RS_SOMEIPSD_00017
Stop Subscribe Eventgroup entries shall set the entry fields exactly like the Subscribe
Eventgroup entry they are stopping, except:
• TTL shall be set to 0x000000.
stop sub的报文 就是把 sub报文中的TTL修改为0x000000
[PRS_SOMEIPSD_00574]
Upstream requirements: RS_SOMEIPSD_00017
A Stop Subscribe Eventgroup Entry shall reference the same options the Subscribe
Eventgroup Entry referenced. This includes but is not limited to Endpoint and Configuration options.
停止订阅和订阅报文不同的另一点 就是 不用携带 options 配置项
5.1.3.1.3 Subscribe Eventgroup Acknowledgement (Subscribe Eventgroup
Ack) Entry 订阅事件组 回复报文
[PRS_SOMEIPSD_00390]
Upstream requirements: RS_SOMEIPSD_00015
The Subscribe Eventgroup Acknowledgment entry type shall be used to indicate that
Subscribe Eventgroup entry was accepted.
回复报文 用来说明 接受client的订阅
[PRS_SOMEIPSD_00391]
Upstream requirements: RS_SOMEIPSD_00015
Subscribe Eventgroup Acknowledgment entries shall set the entry fields in the following way:
• Type shall be set to 0x07 (SubscribeEventgroupAck). -- 固定值
• Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved and
Counter shall be the same value as in the Subscribe Eventgroup that is being
answered.
Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved and
Counter 这些字段的值和 订阅包的保持一致 （entry）
[PRS_SOMEIPSD_00392]
Upstream requirements: RS_SOMEIPSD_00015
Subscribe Eventgroup Ack entries referencing events and notification events that are
transported via multicast shall reference an IPv4 Multicast Option and/or and IPv6
Multicast Option. The Multicast Options state to which Multicast address and port the
events and notification events will be sent to.
options只能携带 IPv4 或 IPv6 组播地址 和 port
[PRS_SOMEIPSD_00829]
Upstream requirements: RS_SOMEIPSD_00015
When receiving a SubscribeEventgroupAck or SubscribeEventgroupNack the Service
ID, Instance ID, Eventgroup ID, and Major Version shall match exactly to the corresponding SubscribeEventgroup Entry to identify an Eventgroup of a Service Instance
收到订阅ack和 订阅失败ack -- 要检查Service ID, Instance ID, Eventgroup ID, and Major Version 等字段严格匹配
5.1.3.1.4 Subscribe Eventgroup Negative Acknowledgement (Subscribe Eventgroup Nack) Entry
[PRS_SOMEIPSD_00393]
Upstream requirements: RS_SOMEIPSD_00015
The Subscribe Eventgroup Negative Acknowledgment entry type shall be used to
indicate that Subscribe Eventgroup entry was NOT accepted.
拒绝订阅回复 -- 表示不接收client的订阅
[PRS_SOMEIPSD_00394]
Upstream requirements: RS_SOMEIPSD_00015
Subscribe Eventgroup Negative Acknowledgment entries shall set the entry fields in
the following way:
• Type shall be set to 0x07 (SubscribeEventgroupAck). -- 固定值
• Service ID, Instance ID, Major Version, Eventgroup ID, Counter, and Reserved
shall be the same value as in the Subscribe that is being answered.
Service ID, Instance ID, Major Version, Eventgroup ID, Counter, and Reserved 字段和订阅包保持一致。
• The TTL shall be set to 0x000000. -- 固定值
[PRS_SOMEIPSD_00566]
Upstream requirements: RS_SOMEIPSD_00015
Reasons to not accept a Subscribe Eventgroup include (but are not limited to):
拒绝订阅的情况可能包含这些 -- 但不仅限于这些
• Combination of Service ID, Instance ID, Eventgroup ID, and Major Version is unknown
• Required TCP-connection was not opened by client
• Problems with the references options occurred
• Resource problems at the Server
• Security association not yet established
[PRS_SOMEIPSD_00527]
Upstream requirements: RS_SOMEIPSD_00015
When the client receives a SubscribeEventgroupNack as answer on a SubscribeEventgroup for which a TCP connection is required, the client shall check the
TCP connection and shall restart the TCP connection if needed.
当client收到 tcp 事件组 订阅失败回复时 要检查自己的TCP是否建链
Note: [PRS_SOMEIPSD_00527] involves checking the state of the network security
protocol
Rational:
The server might have lost the TCP connection and the client has not.
Checking the TCP connection might include the following:
• Checking whether data is received for e.g. other Eventgroups.
• Sending out a Magic Cookie message and waiting for the TCP ACK.
• Reestablishing the TCP connection.
[PRS_SOMEIPSD_00842] Overview of currently supported Entry Types
Upstream requirements: RS_SOMEIPSD_00015
**TCP 连接状态检查** 和 **Entry Types** 的详细解析：
---
### **TCP 连接状态检查**
#### **背景**
在 SOME/IP 协议中，TCP 连接的可靠性非常重要。如果服务器和客户端之间的 TCP 连接出现问题（例如服务器丢失连接，但客户端未感知），可能会导致通信中断或数据丢失。因此，规范 **[PRS_SOMEIPSD_00527]** 提出了检查 TCP 连接状态的机制。
#### **检查方法**
规范中提到了以下几种检查 TCP 连接状态的方法：
1. **检查是否接收到其他事件组的数据**：
- 如果客户端仍然可以接收到其他事件组（Eventgroup）的数据，说明 TCP 连接可能仍然有效。
- 如果没有任何数据接收，可能表明 TCP 连接已断开。
2. **发送 Magic Cookie 消息并等待 TCP ACK**：
- 客户端可以发送一个特殊的 **Magic Cookie 消息** 到服务器，并等待服务器的 TCP ACK 响应。
- 如果收到 ACK，说明 TCP 连接仍然有效。
- 如果未收到 ACK，说明 TCP 连接可能已断开。
3. **重新建立 TCP 连接**：
- 如果检测到 TCP 连接已断开，客户端应尝试重新建立 TCP 连接。
- 重新建立连接的过程包括重新发送 `SubscribeEventgroup` 消息等。
#### **Magic Cookie 消息**
- **作用**：用于检测 TCP 连接是否仍然有效。
- **实现**：
- 客户端发送一个特殊的消息（Magic Cookie）到服务器。
- 服务器收到后，必须回复一个 TCP ACK。
- 如果客户端未收到 ACK，可以认为 TCP 连接已断开。
#### **示例流程**
1. 客户端检测到长时间未收到服务器的数据。
2. 客户端发送 Magic Cookie 消息到服务器。
3. 如果收到服务器的 TCP ACK，继续维持连接。
4. 如果未收到 TCP ACK，客户端尝试重新建立 TCP 连接。
