admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
7.6 KiB
7.6 KiB
覆盖网络 · 应用场景推演完成度 & 方案待完善清单（2026-09-16 检查）
性质：只读检查报告。⛔ 未改任何代码、未动服务器、未写文档库（全局执行锁被
修复轮-决策方法-2b占用）。 检查对象：工作区根覆盖网络线 13 份文档。 📌 口径校正（2026-09-16 11:4x 用户纠正）：本方案的目标应用场景 = ① 多人 + agent 对话 ② MUD / MMORPG 网游 ③ 以上述应用为负载的 1000 台异构网络互联。此前本报告 §一 把"跨机访问实例/文件交换"排在第 1 档，属次级用途，已按用户口径重排。
一、判定：三块场景的「互联逻辑模拟」完成了吗
| # | 应用场景 | 纸面推演 | 可运行模拟 |
|---|---|---|---|
| 1 | 多人 + agent 对话 | ✅ 完成（S2/S4/S5 有数值 + 调研 §2 分档 + 答疑 §一） | ❌ 零 |
| 2 | MUD / MMORPG 网游 | ✅ 完成（S3 有数值 + 游戏专项 12 条 + 调研 §1） | ❌ 零 |
| 3 | 1000 台异构互联（承上述负载） | ✅ 完成（6 类画像 + S1–S11 + 流量预算总表） | ❌ 零 |
结论：
- "文字推演"这一步是完成的 —— 11 个场景逐个有计算、有结论、有处置手段，三块应用都有对应推演。
- "模拟"一步都没开始 —— 全部是纸面演算，零代码、零数据回流。文档自己标注"未接入任何机器"。
- ⇒ 差别在于：现在所有输入数字都是估值（打洞成功率、jitter、每玩家带宽全是估的），文档自己写"关键结论对比例敏感、对绝对值不敏感"。换言之：结构判断可信，具体容量数字还不可信。
二、三块场景的实际覆盖（逐块）
2.1 多人 + agent 对话
| 已推 | 出处 | 数值 |
|---|---|---|
| presence（200 房 × 50 人） | S2 | 8,200 次/秒 |
| presence（1 个 1000 人大房） | S2/S4 | 16,700 次/秒 ← 第一瓶颈 |
| 大房消息扇出 | S2/S4 | 1,000 投递/秒（可承受） |
| agent 放大 | S5 | 无约束 ⇒ 指数增长；四条硬约束 |
- ⭐ 最重要的量化结论：presence 比消息早爆一个量级（16,700 vs 1,000）。
- ⚠️ 缺口 A：agent 预算从头到尾没有标定数值 —— 而 §5 结论却说"单房间实际上限 = min(扇出预算, presence 预算, agent 预算)"。三个预算里有一个是空的 ⇒ 单房间上限目前给不出数。
2.2 MUD / MMORPG 网游
| 已推 | 出处 | 数值 |
|---|---|---|
| 40 服 × 300 玩家，服放 L1 | S3 | 每服 24 Mbps，中继承载 0 |
| 服放家宽（25 服） | S3 | 600 Mbps 常驻 ← 第 2 瓶颈 |
| 攻城战峰值 | S3 | 1.2–2.0 Gbps |
| 抖动门槛 | S3 | jitter < 20 ms |
| 核心简化 | 游戏专项 | 玩家之间不需要互联，中继按服数算 |
- ⚠️ 缺口 B（逻辑跳跃）：S3 推出"服放家宽 ⇒ 600 Mbps 过中继"，但玩家是外部客户端、不是覆盖网络成员 —— 他们凭什么走我们的中继？游戏专项的说法是"服主动拨出到骨干、玩家连骨干入口"，可**"骨干入口"对外开放 = 把中继变成公网游戏入口**，这是完全不同的形态（权限面扩大 + 计费 + 防滥用），这一分支在 13 份文档里没有展开。而它恰好是第 2 大瓶颈的来源。
2.3 1000 台异构网络互联
| 已推 | 数值 |
|---|---|
| 设备构成 | 6 类（云服务器 100 / 家宽 300 / CGNAT 200 / 移动网 150 / 企业网 150 / VPN 100） |
| 需中继占比 | 48.5%（按 45% 设计、55% 留余量） |
| 分场景 | S1–S11 全覆盖（冷启动 / 稳态 / 游戏 / 大房 / agent / 备份 / 迁移 / 中继故障 / 控制面重启 / 区域突变 / NAT 溢出） |
| 流量预算总表 | 10 类流量 × 频率 × 单次 × 放大 × 上限手段 |
- ⚠️ 缺口 C：逐场景独立推，没有并发叠加 —— S1–S11 是串行列举。真实最坏情况是"游戏攻城战 + 备份窗口 + 1000 人大房 + agent 风暴同时发生，且其中 1/3 节点正因中继故障重连"，这一叠加没有任何一份文档推过，而瓶颈排序表是按"单瓶颈先炸顺序"排的。
三、要把"推演"变成"模拟"，还差三件事
- 固化输入参数表（设备占比 / 打洞率 / 每玩家带宽 / 消息频率 / 心跳 —— 现在散在 6 份文档里，无统一表 ⇒ 不可复算）。
- 补并发叠加的最坏情况（缺口 C）。
- 用 3–5 台真机把 3 个关键估值换成实测：打洞成功率、中继 jitter、真实可用带宽 —— 这三个一换，全部容量结论才从"结构可信"变成"数字可信"。
四、方案待完善清单（P0 / P1 / P2）
P0 · 不补就走不通（5 条）
| # | 缺口 | 为什么是 P0 |
|---|---|---|
| 1 | 缺「网（network）」抽象 | 骨干被同时当作"平台 Worker 隧道"与"用户设备 P2P"的会合点，两者权限模型完全不同。13 份文档从未出现"网络标识（tailnet / network id）" ⟹ 所有节点落进同一扁平命名空间，与"可见性默认最小"冲突 |
| 2 | 首次入网引导（bootstrap）无答案 | 会合地址从 env 来，但新设备第一次怎么拿到、首次没有缓存签名目录时怎么办，无人回答 |
| 3 | 地址规划与名字解析无落地设计 | 内部地址段怎么分、如何避开用户内网 10/8 · 192.168/16、split DNS 怎么不破坏用户原 DNS |
| 4 | 信任根与密钥生命周期未设计 | 只写"一机一钥 + 可吊销"，缺控制面签发者（根）的保管与轮换、私钥丢失恢复、设备被盗吊销 |
| 5 | 外部玩家如何进入游戏服（缺口 B） | 决定第 2 大瓶颈（600 Mbps）是否真的存在 —— 若玩家不能进，这条瓶颈根本不成立；若能进，则是权限面扩大（命中 R5） |
P1 · 不做会出事（7 条）
参数表是空的（libp2p 默认值可直接固化）· 30 条未验证项未收敛成取证计划（最该先测 jitter）· 观测最小指标集与阈值缺失 · 权限面评估缺失 = 命中 R5（虚拟网卡驱动需管理员权限 / 骨干开端口 / nft 打洞）· 成本模型缺失 · 滥用与安全事件处置缺失 · 卸载与退出机制缺失 · 协议选型未收敛 · 最小可用规模（3–5 台）路径缺失。
P2 · 一致性与流程（4 条）
首屏口径笔误（瓶颈落地 §3 标题写 10.8 GB，实为 10.8 MB/台）· 落地路线图 4 个版本未收敛 · 10 份文档未归档 · 双源声明与判定句矛盾未修（可行性评估 §6.4 已指出）。
五、唯一主线（收敛 4 个版本后）
| 序 | 动作 | 状态 |
|---|---|---|
| 1 | 会合 / 中继从 Manager 拆出（S0–S4） | 现在就能开工 |
| 2 | 网抽象 + 地址规划 + 引导（P0 1/2/3） | 依赖 ① |
| 3 | 一机一钥 + 信任根（P0-4） | 依赖 ① |
| 4 | 443/TCP 兜底（否则封 UDP 的整类节点进不来） | 依赖 ① |
| 5 | 参数表 + 观测最小集 + 权限评估（P1 三条） | 可并行 |
| 6 | 3–5 台最小形态跑通（把 3 个关键估值换成实测） | 依赖 2/3/4 |
| 7 | 之后才谈：内容分发 · 房间层 · 游戏 | — |
⚠️ 别被 1000 台带偏：1000 是设计上限；当前目标是同一人的几台设备跨公网互通。
六、本次未做（范围声明）
- ⛔ 未写文档库（全局执行锁被占用）；本报告落工作区根。
- ⛔ 未改代码、未在 47 / 106 执行任何命令。
- 📌 未新增上抛项 —— 待拍板仍只有骨干服务范围一项（A 自用 / B 全网，倾向 A→B 渐进）。