4、服务发现状态机：Initial Wait Phase、Repetition Phase、Main Phase 的转换逻辑
SOME/IP 服务发现（SD）的核心，说白了就是一台车上的节点怎么找到另一台车上的服务。我刚开始接触这个协议时，觉得状态机特别绕，后来调了几个实车项目才摸清楚门道。今天咱们就把 Initial Wait、Repetition、Main 这三个阶段掰开揉碎讲清楚。
一句话总结：服务发现状态机控制着节点何时发报文、发多少、发多快。三个阶段分别解决「刚上电别乱叫」「确保大家都收到」「稳定后按需交互」三个问题。
4.1 为什么需要三个阶段？
你想想看，一辆车上有几十个 ECU，一上电如果所有节点同时发服务发现报文，网络瞬间就炸了。所以 SOME/IP 设计了一套「先等、再试、后稳」的机制。
我个人习惯把这三个阶段类比成「面试流程」：
- Initial Wait Phase —— 简历投递前的冷静期，先看看环境
- Repetition Phase —— 反复自我介绍，确保 HR 听到了
- Main Phase —— 入职后按需沟通，没事不打扰
我在项目中遇到过一个问题：某个节点刚上电就发 Offer 报文，结果网关还没初始化完，报文直接丢了。后来查规范才发现，Initial Wait 阶段就是用来避免这种「抢跑」的。
4.2 Initial Wait Phase：先等一会儿
节点上电或网络唤醒后，不会立刻发任何 SD 报文。它会启动一个定时器，时长由配置参数 INITIAL_DELAY 决定，范围通常是 0~100ms（实际项目中我见过设 50ms 的居多）。
| 参数 | 含义 | 典型值 |
|---|---|---|
INITIAL_DELAY |
初始等待时长 | 0~100ms |
INITIAL_REPETITIONS_MAX |
重复阶段最大发送次数 | 3~5 次 |
REPETITIONS_BASE_DELAY |
重复阶段基础间隔 | 10~100ms |
避坑指南：我曾经把 INITIAL_DELAY 设成 0，结果节点上电瞬间和网关同时发报文，在 CAN FD 网络上直接造成总线错误。后来我建议团队至少留 20ms 的余量，给网络稳定留点时间。
这个阶段节点只做一件事：监听。它会收集其他节点发的 Offer 报文，构建本地服务表。如果收到自己需要的服务，就直接进入 Main Phase，不用再发 Find 了。
4.3 Repetition Phase：反复刷存在感
Initial Wait 定时器超时后，节点进入 Repetition Phase。这个阶段的核心逻辑是：以固定间隔重复发送报文，次数有限。
具体流程是这样的：
- 节点发送第一条 Offer（服务端）或 Find（客户端）报文
- 启动重复定时器，间隔 =
REPETITIONS_BASE_DELAY - 每次超时再发一条，直到发满
INITIAL_REPETITIONS_MAX次 - 发完后自动进入 Main Phase
为什么要重复发？我举个例子你就明白了。有一次我在台架上调试，一个节点发 Offer 报文，但对面节点的 CAN 控制器正好在错误恢复阶段，第一条报文直接丢了。好在 Repetition Phase 会发 3 次，第二次就成功握手了。
注意：重复间隔不是固定的。规范允许使用 REPETITIONS_MAX_DELAY 做随机化，防止多个节点同时发报文造成碰撞。实际项目中我建议加上随机抖动，尤其是总线节点超过 10 个的场景。
4.4 Main Phase：稳定期按需交互
进入 Main Phase 后，节点不再主动发重复报文。它进入「被动监听 + 按需响应」模式：
- 服务端：每隔
OFFER_CYCLIC_DELAY（通常 1~3 秒）发一次 Offer，告诉别人「我还活着」 - 客户端：不发 Find，除非发现自己订阅的服务丢了（收到 StopOffer）
- 订阅/取消订阅：通过 Subscribe/SubscribeAck 报文完成，不依赖周期性广播
这个阶段最容易被忽视的是 TTL（生存时间）。每个 Offer 报文都带一个 TTL 值，接收方如果在这个时间内没收到新的 Offer，就认为服务下线了。我见过一个案例：某节点 TTL 设了 3 秒，但 Offer 周期是 5 秒，结果客户端反复报「服务丢失」，其实就是参数配反了。
4.5 状态转换全景图
下面这张图把三个阶段的关系画清楚了。我建议你把它存下来，调试时对照着看。
4.6 实际调试中的关键点
说了这么多理论，咱们聊聊实战。我在调试 SD 状态机时，最常遇到三个坑：
坑一：Initial Wait 时间太短
有些工程师为了「快」，把 INITIAL_DELAY 设成 0。结果节点上电瞬间和网关抢总线，报文全丢。我建议至少 20ms，如果网络上有 CAN FD 或 Ethernet，建议 50ms 起步。
坑二：重复次数和间隔不匹配
假设 REPETITIONS_BASE_DELAY = 100ms，INITIAL_REPETITIONS_MAX = 3，那么整个重复阶段耗时 300ms。如果对面节点在这 300ms 内处于休眠状态，就永远收不到 Offer。我曾经在项目里把间隔改成 50ms，次数改成 5 次，成功率明显提升。
坑三：Main Phase 的 TTL 和周期不匹配
这是最常见的配置错误。TTL 必须大于 OFFER_CYCLIC_DELAY，一般建议 TTL = 周期 × 3。比如周期 1 秒，TTL 设 3 秒，留出两次丢包余量。
4.7 状态机转换的代码示例
下面是一个简化的状态机实现，我用 C 语言风格写出来，方便你理解实际代码中的逻辑：
// 状态机主循环
void sd_state_machine_run(SDNode *node) {
switch (node->phase) {
case INITIAL_WAIT:
if (timer_expired(node->initial_delay_timer)) {
// 进入重复阶段
node->phase = REPETITION;
node->repetition_count = 0;
sd_send_message(node); // 发送第一条
start_timer(node->repetition_timer, node->repetitions_base_delay);
}
break;
case REPETITION:
if (timer_expired(node->repetition_timer)) {
node->repetition_count++;
if (node->repetition_count < node->initial_repetitions_max) {
sd_send_message(node);
start_timer(node->repetition_timer, node->repetitions_base_delay);
} else {
// 达到上限，进入主阶段
node->phase = MAIN;
start_timer(node->offer_cyclic_timer, node->offer_cyclic_delay);
}
}
break;
case MAIN:
if (timer_expired(node->offer_cyclic_timer)) {
sd_send_offer(node); // 周期性发 Offer
start_timer(node->offer_cyclic_timer, node->offer_cyclic_delay);
}
// 处理 StopOffer 或 TTL 超时
if (node->service_lost) {
node->phase = INITIAL_WAIT;
start_timer(node->initial_delay_timer, node->initial_delay);
}
break;
}
}个人建议：实际项目中别把状态机写得太复杂。我见过有人把 Repetition Phase 又拆成三个子状态，结果调试时自己都绕晕了。保持简单，三个阶段足够覆盖 99% 的场景。
4.8 小结
服务发现状态机是 SOME/IP 的基石。Initial Wait 让你别抢跑，Repetition 确保报文不丢，Main 维持稳定通信。记住三个参数：INITIAL_DELAY、REPETITIONS_BASE_DELAY、OFFER_CYCLIC_DELAY，调好它们，SD 基本就稳了。