BLUEPRINT
第八章 可靠性保障
8.1 续传机制
DTP 基于序列号实现续传机制，确保在不稳定的网络环境下保障数据完整传输。
核心目标：连接中断后恢复传输时，无需重新发送已成功接收的数据。
工作原理
发送方 (Sender) 接收方 (Receiver)
│ │
│── Fragment (seq=1) ──────────────▶│ ✓ 接收
│── Fragment (seq=2) ──────────────▶│ ✓ 接收
│── Fragment (seq=3) ──────────────▶│ ✓ 接收
│── Fragment (seq=4) ────── ✗ ──────│ 连接断开
│ │
│ ... 连接恢复 ... │
│ │
│◀── 报告最高已接收序列号 (3) ───────│
│ │
│── Fragment (seq=4) ──────────────▶│ 从断点继续
│── Fragment (seq=5) ──────────────▶│
│ │
发送方职责
- 为每个 Fragment 分配单调递增的序列号
- 在本地缓存尚未被接收方确认的 Fragment
- 收到确认后，从缓存中移除已确认的 Fragment
- 连接恢复后，从接收方报告的最高序列号的下一个 Fragment 开始继续传输
接收方职责
- 跟踪已成功接收的最高序列号
- 连接恢复时，向发送方报告已成功接收的最高序列号
8.2 缓存管理
发送方维护未确认 Fragment 的本地缓存：
- 每个已发送但未收到确认的 Fragment 都保留在缓存中
- 收到确认后，已确认的 Fragment 从缓存中移除
- 缓存有容量上限
缓存已满处理
当发送方的本地缓存达到容量上限时：
- 暂停发送新 Fragment
- 通知上层应用缓存已满
- 等待接收方确认释放缓存空间后恢复发送
8.3 会话管理
会话建立
CAP 完成身份验证和密钥交换后，DTP_Engine 建立一个 DTP 会话，生成唯一的会话标识符（Session_ID）。
会话状态维护
DTP_Engine 在会话中维护双向的传输状态：
| 状态项 | 说明 |
|---|---|
| currentSequenceNumber | 当前序列号 |
| highestAcknowledgedSequenceNumber | 已确认的最高序列号 |
| unacknowledgedFragmentCache | 未确认 Fragment 缓存 |
| activeAgreements | 活跃约定列表 |
每个方向（归集和注入）维护独立的传输状态。
会话持久化
当底层传输连接断开时，DTP_Engine 将会话状态（包括所有活跃约定）持久化存储，以支持后续连接恢复。
会话恢复
连接恢复且 CAP 重新验证通过后，DTP_Engine 恢复之前的会话状态（包括活跃约定）并继续传输。
恢复流程：
- 底层连接重新建立
- CAP 重新验证身份
- DTP_Engine 从持久化存储中恢复会话状态
- 接收方报告已接收的最高序列号
- 发送方从断点继续传输
会话超时
如果会话空闲时间超过协议配置的超时阈值，DTP_Engine 关闭会话并释放相关资源。超时后需要重新建立会话。
8.4 重传机制
当发送方在协议配置的重传超时时间内未收到接收方的确认时，自动重传未确认的 Fragment。
重传策略：
- 等待配置的超时时间
- 超时后重传未确认的 Fragment
- 若重传次数超过阈值，通知上层应用传输失败
8.5 典型场景
场景一：地铁隧道
用户的手机在地铁隧道中断网，已上传了 500 条运动数据中的 300 条。出隧道后恢复连接，DTP 从第 301 条继续传输，无需重传前 300 条。
场景二：蓝牙距离超限
用户的智能手表与手机蓝牙连接因距离过远断开。用户回到手机附近后，连接自动恢复，手表继续上传断开期间积累的心率数据。
场景三：服务器重启
iFay 所在的 FayGer 实例重启，DTP 会话状态已持久化。重启后恢复会话，从断点继续接收终端数据。