Ticketing 响应匹配规则(客户端实现)
由于响应可能相对于请求乱序到达(等待中的获取请求的响应会在轮到它时才到达), 客户端必须按照以下规则将响应与请求配对 —— 这是一套解复用 (demultiplexing) 方案,用于把交错到达在同一连接上的响应正确归类回各自的请求。
| 规则 | 详情 |
|---|---|
| 匹配键 | queue/server capacity满导致确定拒绝；立即返回Busy，不在内部自动重试 |
| 具有相同 (op, key) 的多个请求 | 不得假定 FIFO —— 必须用标识符精确定位。见下文 |
| 注册时机 | 等待者会在请求发送之前注册(以防止响应先到达导致的竞争) |
N/T 的处理 | 作为非错误值返回("不存在" / "已超时") |
B 的处理 | 等待队列已满 —— 不要立即失败,应在 wait 预算内退避重试 |
M 的处理 | 仅保存allowlist中的address为leader hint并关闭连接；没有owner/key，无法关联已发送pending |
L 的处理 | 仅更新leader hint并保持连接；这是server通知，不是请求响应 |
E no_leader / E not_active / E auth_failed | 关闭连接并按错误backoff；no_leader同时清除leader hint |
其他 E / 未知响应 | 无法关联，故connection-fatal；已发送acquire为Indeterminate |
| 没有匹配等待者的响应 | 视为protocol/session不一致并关闭；若为A，将已知exact token交给reserved release lane |
为什么必须用标识符而不是 FIFO 来匹配
即使是同一key，立即成功、queue等待和B拒绝也会在不同时间完成。多个key也在一条连接pipeline，因此响应顺序不等于请求顺序。不要按FIFO匹配；必须同时核对echo的identifier、op与key。
被中止的请求与孤立的锁
被取消的request若已在server grant，lock可能仍存在。发送一个request byte后若没有确定响应，结果就是Indeterminate。不得用相同owner把A当作状态查询重发。只有已parse token时才best-effort发送exact-token R；未知token的grant由lease expiry回收。
发送后cancel或framing error也必须关闭连接；仅丢弃pending会让已发放响应失去接收者。但socket close不能证明已commit grant已release。token已知则发exact-token R，未知则保持Indeterminate直到lease expiry。