Глава 5: Механизм переговоров

5.1 Принципы переговоров

Один из основных принципов проектирования DTP — «приоритет переговоров»: вся передача данных должна основываться на соглашениях, согласованных обеими сторонами — «голой передачи» не существует. Механизм переговоров обеспечивает:

• Master и slave достигают явного консенсуса по параметрам передачи до начала передачи данных
• Параметры соглашения могут динамически корректироваться во время передачи
• Любая сторона может проактивно завершить соглашение

5.2 Типы фреймов переговоров

DTP использует два типа фреймов для завершения переговоров:

Request Frame (Request_Frame)

Используется для инициирования запросов данных или корректировки соглашений о передаче, содержит следующие элементы:

Поле	Описание
requestId	Уникальный идентификатор запроса
requestorRole	Роль запрашивающего (master / slave)
requestType	Тип запроса: collection / injection / adjustment / termination
targetAgreementId	ID соглашения, на которое ссылается при корректировке/завершении
proposedParams	Предлагаемые параметры соглашения

Response Frame (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)             │
  │                                   │

1. Master отправляет Slave запрос на сбор данных, указывая тип данных, режим передачи, частоту и другие параметры
2. Slave отвечает через Response_Frame:
   • Accepted: соглашается передавать данные согласно запрошенным параметрам
   • Rejected: ограничено требованиями соответствия (например, политики DLP предотвращения утечки данных); должна быть указана причина соответствия
   • Counter-proposal: предлагает изменённые параметры

Переговоры об инъекции данных (инициируется Slave)

Slave                               Master
  │                                   │
  │── Request_Frame (injection) ─────▶│
  │                                   │
  │◀── Response_Frame ────────────────│
  │    (accepted + filtered data      │
  │     range / rejected /            │
  │     counter_proposal)             │
  │                                   │

1. Slave отправляет Master запрос на инъекцию данных, описывая, какие данные необходимы
2. Master отвечает через Response_Frame:
   • Accepted: включает отфильтрованный диапазон данных (минимизированный набор)
   • Rejected: данные не будут предоставлены
   • Counter-proposal: предлагает данные в другом диапазоне или формате

5.4 Параметры соглашения

После достижения консенсуса обеими сторонами генерируется уникальный Agreement_ID. Содержание соглашения включает:

Параметр	Тип	Описание
dataType	string	Идентификатор типа данных
dataRange	string	Описание диапазона данных
transferMode	enum	Режим передачи: one_time / periodic / streaming
frequency	number | null	Частота передачи (Гц); 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 одновременно поддерживает соглашение о сборе данных пульса (раз в секунду) и соглашение о сборе данных шагов (раз в минуту) с умными часами; два соглашения работают независимо.