BLUEPRINT

第8章信頼性保障

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 典型的なシナリオ

シナリオ1：地下鉄トンネル

ユーザーのスマートフォンが地下鉄トンネル内で通信が途絶え、500件の運動データのうち300件がアップロード済み。トンネルを出て接続が復旧した後、DTP は301件目から伝送を継続し、最初の300件を再送する必要はありません。

シナリオ2：Bluetooth 距離超過

ユーザーのスマートウォッチとスマートフォンの Bluetooth 接続が距離超過により切断。ユーザーがスマートフォンの近くに戻った後、接続が自動復旧し、ウォッチは切断中に蓄積された心拍データのアップロードを継続します。

シナリオ3：サーバー再起動

iFay が動作する FayGer インスタンスが再起動、DTP セッション状態は永続化済み。再起動後にセッションを復元し、ブレークポイントから端末データの受信を継続します。

第8章 信頼性保障