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 工作階段狀態已持久化。重啟後恢復工作階段，從斷點繼續接收終端資料。