 Horldsence
|
7be8d7d2ba
|
protocol: 更正上一个提交的归因——坏帧不在这里
上一个提交（1c65eaa）说"34 张 JPEG 不完整是重复分片凑数导致的"，并说修完从
34 降到 1。**这个结论是错的**，是我归因到了错误的地方。
实测复查：一到两个订阅者、20 秒 2000+ 个分片，重复投递数为 0（固定端口和
临时端口两种订阅方式都试过）。这条链路上根本不产生重复。
34 张坏帧的真实来源是探测脚本自己：scripts/udp_probe.py 的重组状态只按
sender_id 存，不按 frame_id 存。于是某帧丢了分片之后，下一帧的分片会接着往
同一个计数器里凑，凑够了就交出去一张混着两帧的 JPEG。
FrameAssembler 一直按 frame_id 隔离（换个 frame_id 就重置），所以它没这个
问题——脚本原先跟它不一致，而我又把脚本的输出当成了 crate 的行为。
本次改动：
protocol/src/lib.rs
位图去重保留，理由改为正确性而非正在发生的故障，并在注释里写明实测重复
为 0、以及真正的坏帧来源。删掉一个死变量 `last`。行为不变。
protocol/README.md
"重复分片必须去重" 一节改写：说清防护的定位是"哪天真的重复了"。
新增"按 frame_id 隔离，换帧即放弃"一节，讲清不隔离的具体后果。
记下探到坏帧时先怀疑测量工具。
值得记的不是位图本身，是那个错误归因：34 张坏帧配上"帧率正常、无报错线索"
这个症状，太像一个真的丢包/重复 bug 了，于是一路写到了注释、文档和提交说明
里。以后探到链路异常，先确认测量工具和被测对象说的是同一件事。
|
2026-10-05 19:13:24 +08:00 |
|