BLUEPRINT

第五章協商機制

5.1 協商原則

DTP 的核心設計原則之一是「協商優先」：所有資料傳輸必須基於雙方協商達成的約定（Agreement），不存在「裸傳輸」。協商機制確保：

主端和從端在資料傳輸前對傳輸參數達成明確共識
傳輸過程中可以動態調整約定參數
任何一方可以主動終止約定

5.2 協商幀類型

DTP 使用兩種幀類型完成協商：

請求幀（Request_Frame）

用於發起資料請求或調整傳輸約定，包含以下要素：

欄位	說明
requestId	請求唯一標識
requestorRole	請求方角色（master / slave）
requestType	請求類型：collection（歸集）/ injection（注入）/ adjustment（調整）/ termination（終止）
targetAgreementId	調整/終止時參照的約定 ID
proposedParams	提議的約定參數

回應幀（Response_Frame）

用於回覆資料請求，包含以下要素：

欄位	說明
requestId	對應的請求 ID
result	協商結果：accepted / rejected / counter_proposal
agreedParams	接受或替代方案時的最終參數
agreementId	接受時產生的約定 ID
rejectionReason	拒絕原因

5.3 協商流程

資料歸集協商（Master 發起）

Master                              Slave
  │                                   │
  │── Request_Frame (collection) ────▶│
  │                                   │
  │◀── Response_Frame ────────────────│
  │    (accepted / rejected /         │
  │     counter_proposal)             │
  │                                   │

Master 向 Slave 傳送資料歸集請求，指定資料類型、傳輸模式、頻率等參數
Slave 透過 Response_Frame 回覆：
- 接受：同意按請求參數傳輸資料
- 拒絕：僅限於合規性約束（如 DLP 資料防洩漏策略），必須附帶合規性理由
- 替代方案：提出修改後的參數

資料注入協商（Slave 申請）

Slave                               Master
  │                                   │
  │── Request_Frame (injection) ─────▶│
  │                                   │
  │◀── Response_Frame ────────────────│
  │    (accepted + 過濾後資料範圍 /    │
  │     rejected /                    │
  │     counter_proposal)             │
  │                                   │

Slave 向 Master 傳送資料注入申請，說明需要什麼資料
Master 透過 Response_Frame 回覆：
- 接受：附帶過濾後的資料範圍（最小化資料集）
- 拒絕：不提供資料
- 替代方案：提供不同範圍或格式的資料

5.4 約定參數

雙方達成一致後，產生唯一的 Agreement_ID，約定內容包括：

參數	類型	說明
dataType	string	資料類型標識
dataRange	string	資料範圍描述
transferMode	enum	傳輸模式：one_time / periodic / streaming
frequency	number \| null	傳輸頻率（Hz），一次性模式為 null
validityPeriod	number	有效期（毫秒）
priority	enum	優先級：low / normal / high / critical

5.5 約定生命週期

約定經歷以下狀態：

negotiating ──▶ active ──▶ terminated
                  │
                  ▼
              suspended

negotiating：協商進行中
active：約定生效，資料傳輸中
suspended：連線中斷，約定暫停
terminated：約定終止

5.6 動態調整

DTP 支援在傳輸過程中透過傳送新的 Request_Frame（requestType 為 adjustment）動態調整已有約定的參數。

典型場景：iFay 最初要求智慧手錶每分鐘上報一次心率，但偵測到使用者開始跑步後，動態調整約定為每秒上報一次。

5.7 約定終止

透過傳送 Request_Frame（requestType 為 termination）明確終止一個約定。終止後，該約定下的資料傳輸立即停止。

5.8 多約定並行

DTP 支援在單個工作階段中同時維護多個活躍的約定。多約定的序列或並行傳輸取決於底層傳輸協定的能力。

例如：iFay 同時與智慧手錶維護心率資料歸集約定（每秒一次）和步數資料歸集約定（每分鐘一次），兩個約定獨立運作。

第五章 協商機制