# 通信场景说明

## 系统拓扑
- 系统中有 `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到某个远程端执行操作，一定要确保不做删除文件操作，确保留有记录