Gateway 架构

WinCode Gateway 采用"云端中转 + 本地设备服务"的两层架构。设备之间并不直接建立 P2P 连接,而是都连接到同一台云端中转服务器,由该服务器把消息路由到对端。

整体数据流

┌────────────┐         ┌──────────────┐         ┌────────────┐
│  PC 端     │  WS     │  云端中转    │  WS     │  移动端    │
│  (桌面)    │◀═══════▶│  服务器      │◀═══════▶│            │
└────────────┘         └──────────────┘         └────────────┘
     │                                               │
     │  gateway-status 事件                          │ 扫码配对
     ▼                                               ▼
  gatewayStore                                   PairDialog

1. 桌面端启动时,后端自动向云端 WebSocket 服务发起连接。连接成功后,gatewayStore 接收到 gateway-status 事件,把状态从 connecting 切换为 connected。
2. 移动端启动时,流程相同。
3. 配对时,桌面端通过 gatewayPairToken() 生成一个临时配对码,并渲染为二维码。移动端扫描二维码后,云端中转服务器把两台设备绑定为一个 Binding。
4. 绑定完成后,两台设备即可互发消息。桌面端收到的移动端请求,会先交给本地的 device service 处理,再把结果回传。

状态模型

前端通过 gatewayStore 维护 Gateway 的状态。核心字段有:

• status:来自后端的 GatewayStatusPayload,包含 status 字段(connecting / connected / disconnected)和可选的 retry_in 秒数。
• binding:当前的 BindingInfo,包含 bindingId、deviceId 与 createdAt。为 null 时表示未配对。
• openSessionId:当移动端打开桌面端的某个会话时,通过 gateway-open-session 事件推送,桌面端据此跳转。

状态的变化都通过 Tauri 的事件系统(listen)驱动,而不是轮询。

device service

每台设备的本地 Rust 后端都运行着一个 device service,负责:

• 管理与云端的 WebSocket 连接,包括自动重连。
• 处理从另一台设备发来的请求,例如查询会话列表、转发消息、拉取上下文。
• 把本地的变更(例如新增会话)按需同步给对端。

device service 与聊天进程解耦,即使聊天进程重启,Gateway 的长连接依然可以保持。

相关文档

• Gateway 概览
• 设备配对流程
• 安全模型