OmniSocketGo/CLAUDE.md

通信场景说明

系统拓扑

• 系统中有 A/B/C/D 四个终端。
• A 与 C 在同一侧，B 与 D 在同一侧。
• 实际运行时不是一条端到端 KCP，而是两条独立 KCP 链路：
  • B <-> D
  • D <-> A
• C 只负责 UDP 端口转发。
• 整体目标是让 A 与 B 双向通信：
  • A -> B 发送控制命令
  • B -> A 发送视频和其他反馈数据

网络情况

• 主要瓶颈在 B 侧 5G 链路，A 侧是有线网络，不是主要约束。
• B <-> D 的时延抖动较大：
  • 常见约 15-60 ms
  • 最差约 80-90 ms
• 带宽是明显非对称的：
  • B -> D 约 8 Mbps，偏低且不稳定
  • D -> B 约 27-50 Mbps，更高但也有波动
• 工程含义：
  • 控制流必须优先保障
  • 视频流必须限速并具备自适应能力
  • 不能默认把所有流合成一个共享传输就一定更优

三个项目的角色

• OmniSocketGo
  • 底层传输项目
  • 使用 C 编写
  • 提供 OmniSocket/KCP 传输能力，以及视频发送等原生传输程序
• robot-command-center
  • A 侧上层应用
  • 主要负责接收视频帧，并提供监控/展示能力
  • 当前通过本机 A-side OmniDaemon 使用传输能力
• tienkung-szu
  • 上层控制项目
  • 同时包含 A 侧控制发送和 B 侧控制执行逻辑
  • A 侧典型入口是键盘/Xbox sender
  • B 侧典型入口是 rl_control_node.py / rl_control_node_sim.py，负责接收控制并驱动机器人行为

当前架构方向

• A 侧通过 A-side OmniDaemon 统一管理本机的控制发送和视频接收。
• B 侧通过 B-side OmniDaemon 统一管理本机的控制接收和视频发送。
• 核心原则：
  • 控制流与视频流逻辑分离
  • 每台主机通过本地 daemon 统一持有传输会话
  • 后续围绕真实网络瓶颈做 telemetry、调度和速率自适应

代码原则

• 一定要精简，不能写过于复杂和冗余的代码，因为必须确保各个环节可控，在低延迟的要求下，需要细化各个环节的消耗

SSH原则

• 如果你需要SSH到某个远程端执行操作，一定要确保不做删除文件操作，确保留有记录