BLUEPRINT

第6章データ伝送

6.1 双方向データフロー

DTP は2つの方向のデータ伝送をサポートし、互いに干渉しません：

方向	名称	説明
Terminal → Fay	データ収集	端末で生成されたデータを Personal Data Heap に永続化保存
Fay → Terminal	データ注入	iFay によるフィルタリングと判断を経た最小化データセット

両方向は同一の Logical_Frame フォーマットと処理フローを使用しますが、独立したシーケンス番号空間と再開状態を維持します。

6.2 データ収集フロー（Terminal → Fay）

完全なデータ収集フローは以下のステップを経ます：

端末アプリケーション
  │
  ▼ データ送信
DTP_Slave Engine
  │ 1. コンテキストメタデータを付加
  │ 2. LogicalFrame を構築 (Header + Payload)
  │ 3. Payload を暗号化
  │ 4. LogicalFrame をシリアライズ
  │
  ▼ send(binary_data)
Transport_Adapter
  │
  ▼ onReceive(binary_data)
DTP_Master Engine
  │ 1. LogicalFrame をデシリアライズ
  │ 2. Agreement_ID を検証
  │ 3. Payload を復号
  │ 4. DAG 依存を検証
  │ 5. シーケンス番号を更新 + 確認応答を送信
  │
  ▼ 保存
Personal Data Heap

6.3 データ注入フロー（Fay → Terminal）

完全なデータ注入フローは以下のステップを経ます：

Personal Data Heap
  │
  ▼ データのクエリとフィルタリング
DTP_Master Engine
  │ 1. Fragment + コンテキストメタデータを構築
  │ 2. LogicalFrame を構築
  │ 3. Payload を暗号化
  │ 4. LogicalFrame をシリアライズ
  │
  ▼ send(binary_data)
Transport_Adapter
  │
  ▼ onReceive(binary_data)
DTP_Slave Engine
  │ 1. LogicalFrame をデシリアライズ
  │ 2. Agreement_ID を検証
  │ 3. Payload を復号
  │ 4. シーケンス番号を更新 + 確認応答を送信
  │
  ▼ データ配信
端末アプリケーション

6.4 Agreement_ID 圧縮伝送

伝送オーバーヘッドを削減するため、DTP は Agreement_ID の圧縮伝送をサポートします：

連続する Fragment が同一アグリーメントに属する場合、そのバッチの最初の Fragment のヘッダーにのみ完全な Agreement_ID を含める
後続の Fragment の agreementId フィールドは null に設定し、前回のものを引き継ぐことを示す

受信側の処理ルール：

Agreement_ID を含む Fragment を受信 → 現在のコンテキストの Agreement_ID を更新
Agreement_ID を含まない Fragment を受信 → 現在のコンテキストで最後に宣言された Agreement_ID に関連付け
未知の Agreement_ID を参照する Fragment を受信 → 破棄してエラー通知を送信

例：

Fragment 1: agreementId = "abc-123"  ← 完全な ID
Fragment 2: agreementId = null       ← "abc-123" を引き継ぎ
Fragment 3: agreementId = null       ← "abc-123" を引き継ぎ
Fragment 4: agreementId = "def-456"  ← 新しいアグリーメント、完全な ID
Fragment 5: agreementId = null       ← "def-456" を引き継ぎ

6.5 シーケンス番号管理

単調増加

各 Fragment は伝送シーケンス番号（Sequence_Number）を携帯し、単一セッション内で単調増加します。

双方向独立

データ収集方向とデータ注入方向は完全に独立したシーケンス番号空間を維持します：

データ収集方向 (collection):  seq 1, 2, 3, 4, 5 ...
データ注入方向 (injection):   seq 1, 2, 3, 4, 5 ...

一方の方向のシーケンス番号の変化は他方の方向に影響しません。

6.6 オリジナルタイムスタンプの保全

DTP は各 Fragment のオリジナルタイムスタンプ（Origin_Timestamp）が伝送プロセス全体を通じて不変であることを保証します：

データがソース側で実際に生成された時刻を記録し、伝送時刻ではない
UTC タイムゾーンとミリ秒精度を使用
シリアライズ、暗号化、伝送、復号、デシリアライズを経ても、タイムスタンプは送信前と完全に一致
受信側はオリジナルの Origin_Timestamp を変更せずに保持

これにより、データが遅延アップロードされた場合（オフラインシナリオなど）でも、iFay は真のタイムラインを復元できます。

6.7 DAG 依存検証

受信側は Fragment 受信時に DAG 依存検証を実行します：

サイクル検出：新しい Fragment の依存関係が DAG 内でサイクルを形成しないことを検証。サイクルが検出された場合、その Fragment を拒否
依存解決：依存先の Fragment がまだ到着していない場合、現在の Fragment を「依存解決待ち」状態としてマークしキャッシュ
遅延解決：被依存 Fragment が到着した後、以前にキャッシュされた Fragment を自動的に解決

第6章 データ伝送