BLUEPRINT

제5장 협상 메커니즘

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가 처음에 스마트워치에 분당 1회 심박수 보고를 요구했지만, 사용자가 달리기를 시작한 것을 감지한 후 약정을 초당 1회 보고로 동적 조정한다.

5.7 약정 종료

Request_Frame(requestType이 termination)을 전송하여 약정을 명시적으로 종료한다. 종료 후 해당 약정 하의 데이터 전송은 즉시 중단된다.

5.8 다중 약정 병렬

DTP는 단일 세션에서 여러 활성 약정을 동시에 유지하는 것을 지원한다. 다중 약정의 직렬 또는 병렬 전송은 하위 전송 프로토콜의 능력에 따라 결정된다.

예시: iFay가 스마트워치와 심박수 데이터 수집 약정(초당 1회)과 걸음 수 데이터 수집 약정(분당 1회)을 동시에 유지하며, 두 약정은 독립적으로 운영된다.