目录标题
- vSomeIP 服务发现（SD）与 Availability 工程化：上线/下线、重启恢复、超时与重试策略
- 1. SD 的底层机制：为什么 TTL 与“相位（phase）”决定了可用性语义
- 1.1 SD 并不是“找一次就完事”，而是持续的分布式心跳
- 1.2 TTL：服务失效检测的根基，以及 Stop Offer 的特殊语义
- 1.3 初始等待、重复与主阶段：为什么“启动风暴”需要被抑制
- 1.4 难点对照表：把 SD 抽象语义映射成工程可观察量
- 2. vSomeIP 如何落地 SD：配置项、必需参数、以及与 API 的契合方式
- 2.1 service-discovery 的必需项：多播地址、端口、协议
- 2.2 一组典型 SD 参数：它们分别控制哪一段状态机
- 2.3 API 与 SD 的分工：offer/request 与 availability 的职责边界
- 2.4 典型时序：用最少机制获得“可恢复”的通信链路
- 3. 工程化策略：上线/下线、重启恢复、超时与重试（从“能通”到“抗抖动”）
- 3.1 把 availability 当成状态机，而不是回调事件
- 3.2 服务端：显式下线优于被动超时（但要兼容崩溃场景）
- 3.3 客户端：超时与重试不应“盲重试”，而应分层治理
- 3.4 “重启恢复”的三个工程细节：最常踩坑的地方
- 3.5 一份可直接落地的“参数与策略联动”建议清单
- 结语
vSomeIP 服务发现（SD）与 Availability 工程化：上线/下线、重启恢复、超时与重试策略
SOME/IP 的强项在于“服务导向”，而服务导向能否在车载/嵌入式网络里稳定运行，核心不在 RPC 本身，而在Service Discovery（SD）与可用性（Availability）：服务何时被发现、何时被判定失效、失效后怎样恢复、应用层如何做超时与重试，决定了系统是否“看似能跑”还是“长期稳定”。vSomeIP 将 SD 作为独立模块实现（例如libvsomeip3-sd.so），并通过配置与回调将其暴露给应用层。
1. SD 的底层机制：为什么 TTL 与“相位（phase）”决定了可用性语义
1.1 SD 并不是“找一次就完事”，而是持续的分布式心跳
在 SOME/IP SD 模型中，Server 侧会周期性发送OfferService（提供服务），Client 侧在需要时发送FindService（查找服务），两者依靠网络与定时器形成“持续一致性”。因此可用性不是一个静态布尔值，而是一个
