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 同时与智能手表维护心率数据归集约定（每秒一次）和步数数据归集约定（每分钟一次），两个约定独立运行。

第五章 协商机制