找到「能播,但每隔一阵子就重载一次」的真凶:服务端要求更新播放令牌时,我们把令牌的文本形式当成了令牌本身发出去 —— 服务端必然判它无效,于是整场会话被处决。本版修掉这一处,并把它收敛成唯一入口,防止再分叉。
变更
- 令牌更新改为「先解码、再发送」(P11-141)。服务端要求更新令牌时(会话内状态
status=2),我们换上去的那枚令牌此前是原样的文本(实测日志里「208 字节」正好等于「208 个字符」—— 完全没有解码),而正确形态是解码后的字节。会话创建时早就是这么做的,只有刷新这条路径漏了:于是服务端每要求刷新一次,我们就把一枚本来能用的令牌换成必被拒的字节,紧接着的每个请求都被判「令牌无效」,会话一路走到死(重载)。 - 刷新日志带上更新前后的字节数(形如
120B → 88B),「有没有解码」从此在日志里一眼可判 —— 这正是本轮判读的依据,也留给下一轮当验收判据。
进展与已知问题
- 本轮排除掉一个此前的主要怀疑:刷新用的令牌铸造器与首次铸造是同一个实例、没有重建,访客标识也相同 ⇒ 不是「用另一套身份铸令牌」,问题纯粹出在编码。
- 同一份日志留下三项未修的问题,下轮处理:①采集材料所建的会话只提供「浏览器当时自己选的那两档」格式(实测两分钟内 275 次被丢弃的格式全是它们),而我们固定要另外两档 ⇒ 两边永远对不上;②「跟着服务端实际提供的档位选档」这一策略会被起播期的锁档夹回固定档位,等于从未生效;③采集材料所建的会话在音频侧也无法满足我们(材料只供一种音频格式)。反面证据同时拿到:用我们自己的会话地址 + 采集来的令牌,格式是正常供的 ⇒ 问题在会话地址(服务端按采集那一场绑定格式供流),不在令牌。
- WEB-SABR 仍不作为日常播放主路;会话被判死时会自动换到能播的路线(alpha.11 起),日常观看不受影响。