跳到主要内容

连接状态

本章节定义初版 NRCP over QUIC 的连接状态机。该版本连接状态只描述 QUIC 连接、NRCP 会话可用性、心跳异常、恢复流程与关闭流程

NRCP 连接状态是每个 Endpoint 的本地观察结果,不是双方强一致共享状态。Client 与 Server 可能在短时间内处于不同状态,接收端必须以自己的本地状态决定是否处理收到的消息

状态定义

状态适用端含义允许行为
DISCONNECTED双方未建立 QUIC 连接无业务消息
CONNECTINGClientQUIC 连接建立中,包含内部 TLS 1.3 握手无 NRCP 业务消息
CONNECTED双方QUIC 握手完成,NRCP 会话可用Operation、Flow、Heartbeat
DEGRADED双方QUIC 仍连接,但 NRCP 心跳或业务活性异常停止高危控制类消息,可继续关闭或恢复流程
RECOVERINGClientClient 正在同一 QUIC 连接上恢复 NRCP 层会话状态停止高危控制类消息,重新建立 NRCP 状态
CLOSING双方连接关闭中拒绝新 Operation 与新 Flow,释放已有资源

状态迁移

Client 侧典型状态迁移如下:

DISCONNECTED
-> CONNECTING
-> CONNECTED
-> DEGRADED
-> RECOVERING
-> CONNECTED

CONNECTED
-> CLOSING
-> DISCONNECTED

DEGRADED
-> CLOSING
-> DISCONNECTED

Server 侧典型状态迁移如下:

DISCONNECTED
-> CONNECTED
-> DEGRADED
-> CONNECTED

CONNECTED
-> CLOSING
-> DISCONNECTED

DEGRADED
-> CLOSING
-> DISCONNECTED

Server 不主动建立 QUIC 连接,因此没有 CONNECTING。Server 不主动恢复 Client,因此没有 RECOVERING

典型触发条件:

  • Client 发起 QUIC 连接时进入 CONNECTING
  • QUIC 握手完成后进入 CONNECTED
  • QUIC 仍连接,但心跳超时、连续丢包或路径质量明显恶化时进入 DEGRADED
  • Client 决定在同一 QUIC 连接上恢复 NRCP 层会话状态时进入 RECOVERING
  • 任一端主动关闭、收到关闭通知或发生不可恢复错误时进入 CLOSING
  • QUIC 连接断开时直接进入 DISCONNECTED,旧 NRCP Session 立即失效;

NRCP 不直接管理 TLS 状态。TLS 1.3 握手由 QUIC 连接建立过程完成,应用层只要求 QUIC 握手完成后才能发送 NRCP 业务消息

本地状态原则

由于心跳双向独立发送,网络异常可能是非对称的,因此双方状态不要求同时迁移。以下组合都是允许出现的短暂状态:

Client 状态Server 状态含义
CONNECTEDDEGRADEDServer 认为 Client 活性异常,但 Client 尚未发现异常
DEGRADEDCONNECTEDClient 认为 Server 活性异常,但 Server 尚未发现异常
RECOVERINGDEGRADEDClient 正在发起恢复,Server 仍认为当前 Session 异常

协议处理遵循以下原则:

  • 发送端只能根据自己的本地状态决定是否发送消息;
  • 接收端必须根据自己的本地状态决定是否处理消息;
  • 接收端本地状态拥有最终处置权;
  • 发送端不能以自身处于 CONNECTED 作为消息应被执行的依据;
  • 双方通过 Heartbeat、Error、恢复请求和 Flow 重建逐步收敛状态;

状态行为

CONNECTED

CONNECTED 是正常工作状态,双方允许执行以下行为:

  • 周期性发送 Heartbeat Ping;
  • 响应 Heartbeat Pong;
  • 发起 Operation;
  • 创建、更新和关闭 Flow;
  • 接收状态数据和控制数据;

进入 CONNECTED 后,Heartbeat 与时钟同步必须持续维护。Flow 只能在本地状态为 CONNECTED 时建立和运行

DEGRADED

DEGRADED 表示底层 QUIC 连接仍存在,但 NRCP 会话不再可信地满足实时通信要求

进入 DEGRADED 后:

  • 双方应停止发送新的高危控制类消息;
  • Server 应使机器人进入安全降级状态;
  • Client 应停止依赖当前 NRCP 会话,并准备恢复 NRCP 层状态;
  • 已建立的 Flow 可按业务策略暂停、关闭或等待恢复;

进入 DEGRADED 后,Endpoint 不得建立新 Flow,也不得将收到的 FLOW_DATA 交给业务处理逻辑

当 Endpoint 本地处于 DEGRADED 时,它不得执行来自该 Session 的高危控制类消息。若传输条件允许,应返回明确错误;若无法可靠返回错误,允许直接丢弃

典型错误码包括:

  • SESSION_DEGRADED
  • HEARTBEAT_TIMEOUT
  • CONTROL_SUSPENDED

若 QUIC 连接已经断开,则不再进入或停留在 DEGRADED,而是直接进入 DISCONNECTED

RECOVERING

RECOVERING 只存在于 Client 本地状态机,用于表示 Client 正在同一 QUIC 连接上恢复 NRCP 层会话状态。Server 不主动恢复 Client,也不需要进入 RECOVERING

Client 进入 RECOVERING 后:

  • 停止发送高危控制类消息;
  • 重新执行 NRCP 层恢复流程;
  • 重新建立必要 Flow;
  • 等待当前 QUIC 连接上的 NRCP 会话重新进入 CONNECTED

心跳恢复不应直接使状态从 DEGRADED 自动回到 CONNECTED。心跳连续恢复只表示链路具备恢复条件,Client 应进入 RECOVERING 并主动发起 NRCP 层恢复流程。只有恢复流程完成后,Client 才能回到 CONNECTED

恢复流程必须覆盖以下步骤:

  • 确认当前 QUIC 连接仍然存在;
  • 确认旧 NRCP Session 未超过恢复窗口;
  • 重新同步或重建必要 Flow;
  • 重新确认 QoS Grant 是否仍有效;
  • 重置本地 Sequence、去重窗口和缓存状态;
  • 重新建立有效的时钟偏移估计;

Server 收到恢复请求后,只根据当前 Session、Flow、QoS 和资源状态响应恢复结果,不需要进入 RECOVERING

恢复结果取值如下:

  • RECOVERED:旧 NRCP Session 可继续使用;
  • REBUILD_REQUIRED:旧 NRCP Session 可用,但 Flow 需要重建;
  • SESSION_EXPIRED:旧 NRCP Session 已失效;

初版不提供跨 QUIC 连接的 Session 恢复机制。若 QUIC 已经断开,Client 必须新建 QUIC 连接,新连接视为全新的 NRCP Session

消息处置规则

Endpoint 收到消息时,应先根据本地状态判断是否允许处理:

本地状态收到普通 Operation收到 Flow 数据收到高危控制类消息收到 Heartbeat收到恢复请求
CONNECTED允许允许按业务规则校验允许按本地策略处理
DEGRADED可拒绝或降级处理可暂停或丢弃必须拒绝或丢弃允许Server 可处理
RECOVERINGClient 本地暂停Client 本地暂停Client 本地暂停允许Client 等待响应
CLOSING拒绝丢弃丢弃可忽略拒绝

若 Server 已进入 DEGRADED,而 Client 仍处于 CONNECTED 并继续发送控制指令,Server 必须以自己的 DEGRADED 状态为准拒绝或丢弃该控制指令。Client 可通过 Error 或后续心跳超时发现异常并进入 DEGRADEDRECOVERING

CLOSING

进入 CLOSING 后,Endpoint 应拒绝新的 Operation 和新的 Flow,并开始释放资源

需要释放的资源包括:

  • 未完成 Operation;
  • 未完成 Flow 协商;
  • 已建立 Flow 上下文;
  • QoS Grant;
  • 心跳和时钟同步状态;
  • 重传、去重和 Rate Limiter 状态;

与心跳的关系

心跳用于驱动 CONNECTEDDEGRADED 的状态迁移。具体超时公式和 NRCP 层恢复窗口见心跳与时钟同步

连接状态机只规定状态迁移与资源处理,心跳章节负责定义 Heartbeat Ping/Pong、超时判断、NRCP 层恢复窗口和时钟同步采样