admin
c1b5e4d966
- 变更规模：新增 514 / 修改 62 / 重命名 155 / 删除 4（归档重组与文档轮次） - .gitignore 修：`归档/**/db-cwd归一-备份-*/` —— 原规则写绝对层级（归档/db-cwd归一-…）， 目录搬进 归档/配置与备份/ 后**静默失效**，43 MB 的 DB 备份又变成未跟踪 - .gitignore 补：嵌套 git 内部数据（归档/内嵌git-20261008/、归档/skills-git-旧线-20261007/dotgit-原样移出/） - .gitignore 补：运行态与部署副本（.workbuddy/collab/、.workbuddy/tools/、.workbuddy/.load-pending、.workbuddy/tmp-*） - .gitignore 补：备份件（*.bak-*） - 未跟踪文件从 2190 降到 890（其余为 归档/ 归档件与 .workbuddy/memory/ 知识文件，按口径入库）
5.7 KiB
5.7 KiB
交付物 · 端口决策 ＋ 设备当中继可行性（2026-09-25/26）
工作区：
E:/ProgramData/AIProject/aliyun-dsh-server｜基线：D:/github/dsh_shenxian（只读） 用户两条口径：① 先不开端口，后续有需要再开 ② 可让性能与网速高的设备当中继，如桌面客户端版本
§1 拍板 ①：先不开端口（已定）
| 状态 | |
|---|---|
D8 云安全组（47/106 入站 UDP 21100–21115 放对端 /32） |
🔴 用户拍板：暂不开（后续有需要再开） |
| 影响 | 真机 P2P 打洞率仍为 0 ⇒ 内容面跨节点分发的带宽节省（实测潜力 75–93.75%）暂时拿不到 |
| ⛔ 不影响 | 群聊 / 房间 / 消息 / 历史 / 在线态 / 插件 —— 全走 443 中继，功能完整可用 |
| 重开条件 | 要做跨节点内容分发（插件内容 / 大文件 / 镜像同步），或消息面直连被证明确有收益时 |
§2 拍板 ②：设备当中继 —— 🔴 路径已存在，但要分清两个角色
§2-1 现成基础（实证，⛔ 不是设想）
| 件 | 状态 |
|---|---|
覆盖网节点接入（overlay-node-join.cjs / overlay-node-admit.cjs） |
✅ 已落地：控制面签一次性邀请凭据 → 节点侧一条命令四步全自动（私钥不出机）→ 批准 → 投影成白名单 |
| 中继白名单机制 | ✅ dialers: Map<network, Set<hostId>>、默认拒绝（没列到的一个都拨不动）⇒ 加节点 = 配置动作，任何设备都能登记 |
| 分组 / 独立组网 | ✅ 零代码：新增一个 networkId 即是一张独立网 |
| 桌面端节点接入 | ✅ 已实测（dsh-ai1net-desktop/docs/S2_覆盖网络节点接入编排与守护实测报告_20260920.md）—— 客户端接线 / 身份准入 / 守护（退避自愈、永不放弃、开机自启）/ 验收脚本全就位 |
| 一条命令既起服务端也起客户端 | ✅ lib/net/relay/main.js：--client（拨出）／--port --keys-file --base --span（起服务端 = 中继） |
🔴 ⇒ 结论：桌面端"能当节点"已实测；"能起中继服务端"是同一个入口的另一种模式 —— 技术路径通，⛔ 不需要新造协议。
§2-2 🔴 但必须分清两个角色（这是关键）
| 角色 | 做什么 | 需要"可达"吗 | 现状 |
|---|---|---|---|
拨出方（--client） |
连到中继，把自己的实例口注册出去 | ⛔ 不需要（NAT 允许出站） | ✅ 已实测 |
中继 / 被拨入方（--server） |
监听并替别人转发 | ✅ 需要：别人得能连到它 | ⚠️ 未实测 |
⇒ 你说"设备当中继"＝要的是第二个角色。它比第一个多一道门槛：其他节点得能连上这台设备。
§2-3 🔴 一个容易混淆的点：设备当中继也有它自己的"端口问题"
⛔ 这不是服务器云安全组那件事，而是用户自己那侧的网络：
- 设备在家庭/公司 NAT 后面 ⇒ 外网连不进来 ⇒ 不能被当中继（除非：公网 IP、路由器端口映射/UPnP、或打洞成功）。
- ⚠️ 所以"先不开端口"这个决定与"设备当中继"不冲突（一个是服务器的，一个是用户设备侧的），但设备当中继自己也有可达性门槛 —— ⛔ 别以为"换设备当"就绕开了全部网络前提。
✅ 但有一类场景几乎零门槛：同一局域网 / 同一组织内网（公司内几台高性能机器互为中继）—— 内网直连不需要任何公网端口，立即可用。
§2-4 ✅ 一条完全不需要任何端口的替代路径（推荐先试）
不用"设备当中继"，改成"设备主动拉"（业界叫 fan-out on read）：
服务器收到消息 → 只落库 + 广播一条**小信令**（"某房有新消息"）
→ 各设备**主动拨出**去拉消息（拨出不需要可达、不需要端口）
| 设备当中继 | 设备主动拉 | |
|---|---|---|
| 端口/可达性 | ✅ 需要（用户侧 NAT 要能进） | ❌ 不需要（只出站） |
| 卸载服务器扇出 | ✅ 真正卸载（服务器少写 N 次） | ✅ 同样卸载（服务器不再逐连接写） |
| 消息延迟 | 低 | 略增（一次拉取往返） |
| 现成度 | 中继服务端已有，接入机制已有 | ⚠️ 需接线（我上一棒的插件 subscribe 轮询已是雏形） |
🔴 我的判断：若目标是"给服务器减负"，"设备主动拉"性价比明显更高——省的是同一块成本，却不需要用户侧任何网络前提。⚠️ 但要先把轮询做对（现在是固定间隔轮询，随设备数线性增长 ⇒ 得改成"信令触发 + 增量拉"）。
§3 与既有技术路线的关系
已拍板的技术路线是「引入 Centrifugo 类外部连接层」，而连接层支持多实例。
⇒ 你的设想在架构上 = 把连接层的节点来源，从"只由平台提供"扩展为"平台 ＋ 用户自备高性能设备"。 这与既有方向一致，⛔ 不改架构；且已有现成机制（白名单 ＋ 一键加入 ＋ 桌面端守护）。
§4 建议的推进顺序（技术项，可自决）
- 先做「设备主动拉」的改造（无网络前提、收益同向）—— 把轮询改成信令触发 + 增量拉。
- 同时在局域网场景小范围试"设备当中继"（零公网前提，验证中继服务端角色）。
- 跨公网设备当中继留到确实需要时 —— 届时与"是否重开端口"一起定（两者同源）。
§5 边界
⛔ 本件零代码改动、未部署、未 commit/push、未动 47/106、未动云安全组、未改桌面线一个字节（只读）。 ⛔ 未登记下一棒。