4. SOMEIP-SD 深度解析：服务发现报文类型、Offer/Subscribe/StopOffer 机制、会话管理
SOMEIP-SD，说白了就是车载以太网里的「服务广播站」。没有它，各个 ECU 根本不知道谁提供了什么服务、谁需要什么服务。我刚开始接触 SOMEIP 时，总觉得 SD 就是个简单的发现协议，直到在项目中排查一个服务订阅超时的 bug，才真正领教了它的细节有多重要。
4.1 服务发现报文类型
SOMEIP-SD 的报文类型不多，但每一种都有明确的用途。我个人习惯把它们分成两类：主动宣告和请求应答。
| 报文类型 | 方向 | 用途 |
|---|---|---|
| OfferService | Server → Multicast | 服务端主动宣告自己提供了某个服务 |
| FindService | Client → Multicast | 客户端寻找某个服务 |
| SubscribeEventgroup | Client → Server | 客户端订阅某个事件组 |
| SubscribeEventgroupAck | Server → Client | 服务端确认订阅 |
| SubscribeEventgroupNack | Server → Client | 服务端拒绝订阅 |
| StopOfferService | Server → Multicast | 服务端停止提供服务 |
你可能会问：为什么要有 FindService？直接等 OfferService 不行吗？嗯，这里要注意——如果客户端启动比服务端晚，或者服务端重启了，客户端总不能一直干等吧？FindService 就是用来主动「喊一嗓子」的。
4.2 Offer/Subscribe/StopOffer 机制
这三个机制构成了 SOMEIP-SD 的核心生命周期。我画了一张图，帮你理清它们之间的关系。
4.2.1 OfferService 机制
服务端启动后，会周期性地发送 OfferService 报文。这个周期由 RepetitionPhase 控制：
- 初始阶段：快速发送（比如 100ms 间隔），让客户端尽快发现服务
- 稳定阶段：慢速发送（比如 2s 间隔），仅用于保活
我在项目中遇到过一个问题：某个服务端在启动后只发了 3 次 OfferService 就停了，结果客户端刚好在第 4 次启动，永远收不到 Offer。后来发现是 RepetitionMax 配置得太小了。嗯，这里要记住——OfferService 的发送次数和间隔必须覆盖客户端的最晚启动时间。
4.2.2 SubscribeEventgroup 机制
客户端收到 OfferService 后，会发送 SubscribeEventgroup 报文。这里有个关键点：订阅是针对 Eventgroup 的，不是针对 Service 的。
一个 Service 可以包含多个 Eventgroup，每个 Eventgroup 对应一组事件和方法。比如一个「车身控制服务」可能有：
- Eventgroup 1：车门状态事件
- Eventgroup 2：车窗控制方法
- Eventgroup 3：车灯状态事件
客户端可以只订阅它关心的 Eventgroup，不用全收。我曾经见过一个设计，把所有事件都塞进一个 Eventgroup，结果客户端不得不处理大量无关数据——说白了，就是 Eventgroup 粒度没设计好。
关键参数：TTL（Time To Live）
每个 SubscribeEventgroup 报文都带一个 TTL 字段。服务端收到后，会启动一个定时器，如果 TTL 超时前没有收到续订报文，就认为客户端已离线，自动取消订阅。
我建议 TTL 设置为订阅周期的 3 倍，避免网络抖动导致误判。
4.2.3 StopOfferService 机制
服务端要下线时，会发送 StopOfferService 报文。客户端收到后，必须立即停止使用该服务，并重新发起 FindService 或等待新的 OfferService。
你可能会想：如果服务端突然 crash 了，来不及发 StopOffer 怎么办？嗯，这就是 TTL 的另一个作用——客户端发现服务端长时间不发 OfferService（TTL 超时），也会认为服务不可用。
避坑指南：StopOffer 的时机
我曾经在项目中遇到一个 case：服务端在停止服务前先发了 StopOffer，但此时还有客户端正在通过该服务传输数据。结果数据传了一半，客户端收到 StopOffer 后直接丢弃了后续报文，导致数据不完整。
正确的做法是：先停止数据传输，等待所有 pending 请求完成，再发送 StopOffer。
4.3 会话管理
SOMEIP-SD 的会话管理，说白了就是「谁在什么时候订阅了什么服务，什么时候该续约，什么时候该释放」。
4.3.1 会话状态机
每个客户端-服务端对都有一个隐式的会话状态机：
| 状态 | 触发条件 | 行为 |
|---|---|---|
| Initial | 系统启动 | 等待 OfferService 或发送 FindService |
| Ready | 收到 OfferService | 可发送 SubscribeEventgroup |
| Subscribed | 收到 SubscribeEventgroupAck | 正常接收事件数据 |
| Pending | 发送 SubscribeEventgroup 后等待 Ack | 重试或超时处理 |
| Terminated | 收到 StopOffer 或 TTL 超时 | 释放资源，回到 Initial |
4.3.2 续订机制
订阅不是一次性的。客户端必须在 TTL 超时前重新发送 SubscribeEventgroup 来续订。我个人的习惯是：
- 在 TTL 还剩 1/3 时发起续订
- 如果连续 3 次续订失败，认为服务端已不可达
- 不要等到 TTL 归零才续订，避免网络抖动导致服务中断
小技巧：续订报文的处理
服务端收到续订 SubscribeEventgroup 时，如果该客户端已经处于 Subscribed 状态，直接重置 TTL 定时器即可，不需要重新发送 Ack。这样可以减少不必要的网络流量。
4.3.3 多客户端场景下的会话管理
一个服务端可能同时服务几十个客户端。每个客户端都有自己的 TTL 定时器。服务端需要维护一张订阅表：
// 伪代码示例：服务端订阅表
struct SubscriptionEntry {
uint16_t client_id;
uint16_t eventgroup_id;
uint32_t ttl; // 剩余时间 (ms)
uint32_t remaining_ttl; // 当前 TTL 倒计时
bool is_active;
};
// 定时器回调：每秒检查一次
void check_subscriptions() {
for each entry in subscription_table {
entry.remaining_ttl -= 1000;
if (entry.remaining_ttl <= 0) {
// TTL 超时，移除订阅
remove_subscription(entry.client_id, entry.eventgroup_id);
// 可选：通知应用层
notify_subscription_lost(entry.client_id, entry.eventgroup_id);
}
}
}我在实际项目中，这张表最多管理过 200 多个客户端。嗯，这里要注意——定时器的精度和遍历效率。如果每个客户端都用一个独立的定时器，系统开销会很大。我建议用一个全局的 1ms 或 10ms 定时器，统一遍历所有订阅条目。
4.4 常见问题与避坑
- OfferService 和 FindService 的冲突：如果客户端和服务端同时启动，可能会出现双方同时发送报文的情况。SOMEIP-SD 规范要求服务端优先响应 FindService，但客户端也要做好重复 OfferService 的处理。
- 多播风暴：如果网络中有大量服务端同时发送 OfferService，多播流量可能暴涨。我建议在 RepetitionPhase 中引入随机延迟，避免所有服务端在同一时刻发送。
- 订阅超时：客户端发送 SubscribeEventgroup 后，如果长时间收不到 Ack，不要无限重试。设置一个最大重试次数（比如 3 次），超过后认为服务端不可用。