Глава 3: Архитектура протокола
3.1 Уровневая структура протокола
DTP использует многоуровневую архитектуру, сверху вниз:
┌─────────────────────────────────────────────┐
│ Прикладной уровень │
│ iFay / coFay / Personal Data Heap │
│ Терминальные приложения (ПО / Оборудование)│
├─────────────────────────────────────────────┤
│ Уровень протокола DTP │
│ DTP_Master Engine / DTP_Slave Engine │
│ ┌───────────────────────────────────────┐ │
│ │ Agreement Manager │ │
│ │ Frame Codec │ │
│ │ DAG Manager │ │
│ │ Encryption Module │ │
│ │ Session Manager │ │
│ │ Resume Manager │ │
│ └───────────────────────────────────────┘ │
├─────────────────────────────────────────────┤
│ Уровень адаптера │
│ Transport_Adapter │
├─────────────────────────────────────────────┤
│ Транспортный уровень │
│ BLE / WebSocket / TCP / RTSP / ... │
└─────────────────────────────────────────────┘
Принципы проектирования
- Транспортная агностичность: через абстракцию Transport_Adapter основная логика DTP отделена от конкретных транспортных протоколов
- Приоритет переговоров: вся передача данных должна основываться на соглашениях, согласованных обеими сторонами — «голой передачи» не существует
- Суверенитет данных: master обладает окончательной властью принятия решений по потокам данных; slave является производителем или потребителем данных
- Сквозное шифрование: Payload шифруется при передаче; среда выполнения FayGer не имеет доступа к данным в открытом виде
- Сохранение контекста: каждый Fragment несёт структурированные контекстные метаданные, обеспечивая сохранение контекста при сборе данных
- Восстанавливаемость: механизм возобновления на основе порядковых номеров поддерживает бесшовное восстановление после разрывов соединения
3.2 Основные компоненты
DTP_Engine
Ядро обработки протокола DTP, доступное в двух вариантах:
- DTP_Master: работает на стороне Fay; обладает правом инициировать сбор данных и принимать решения по инъекции данных
- DTP_Slave: работает на стороне терминала; отвечает за производство данных и запросы на инъекцию
Оба варианта разделяют базовые возможности — кодек фреймов, шифрование и управление DAG, — но различаются в правах на переговоры и направлении потока данных.
Transport_Adapter
Абстрактный интерфейс для нижележащих транспортных протоколов. DTP_Engine взаимодействует с конкретными транспортными протоколами через этот интерфейс, обеспечивая транспортную агностичность. Поддерживаемые транспортные протоколы включают BLE, WebSocket, TCP, RTSP и другие.
При разрыве нижележащего транспортного соединения Transport_Adapter сообщает DTP_Engine о событии изменения состояния соединения, запуская приостановку сессии и процесс возобновления.
Agreement Manager
Управляет полным жизненным циклом соглашений:
- Создание: инициирует запрос на переговоры
- Переговоры: обрабатывает запросы и ответы
- Активация: генерирует Agreement_ID после достижения консенсуса обеими сторонами
- Динамическая корректировка: изменяет параметры соглашения во время передачи
- Завершение: прекращает соглашение по директиве остановки
Frame Codec
Отвечает за сериализацию LogicalFrame (кодирование в двоичный формат) и десериализацию (декодирование из двоичного формата), а также форматированный вывод (Pretty Print). Обеспечивает корректную передачу фреймов между различными платформами.
DAG Manager
Управляет зависимостями направленного ациклического графа между Fragment:
- Обнаружение циклов: предотвращает формирование циклических зависимостей
- Разрешение зависимостей: обрабатывает случаи, когда целевые зависимости ещё не прибыли
- Запросы связей: запрашивает зависимости и зависимые элементы Fragment
Encryption Module
Отвечает за сквозное шифрование и дешифрование Payload с использованием ключей, предварительно согласованных CAP. Гарантирует, что среда выполнения FayGer не имеет доступа к данным в открытом виде.
Session Manager
Управляет жизненным циклом сессий DTP:
- Создание и закрытие сессий
- Сохранение и восстановление состояния
- Обнаружение тайм-аутов и освобождение ресурсов
Resume Manager
Управляет механизмом возобновления на основе порядковых номеров:
- Управление кэшем Fragment
- Отслеживание порядковых номеров
- Координация восстановления с точки прерывания
3.3 Конечный автомат DTP_Engine
Рабочие состояния DTP_Engine описываются следующим конечным автоматом:
┌──────────────────────────────────────────┐
│ │
┌───────┐ │ ┌──────────────┐ ┌────────────────┐ │
│ Idle │──────┼─▶│WaitingForCAP │───▶│SessionEstablished│ │
│ │◀─────┼──│ │◀───│ │ │
└───────┘ │ └──────────────┘ └───────┬────────┘ │
▲ │ │ │
│ │ ▼ │
│ │ ┌─────────────┐ │
│ │ │ Negotiating │ │
│ │ └──────┬──────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌──────────────┐ │
│ │ │ Transmitting │ │
│ │ └───────┬──────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌──────────┐ ┌─────────────┐ │
└──────────┼──│ Resuming │◀─────│ Suspended │ │
│ └──────────┘ └─────────────┘ │
└──────────────────────────────────────────┘
Описание переходов состояний:
| Текущее состояние | Событие-триггер | Целевое состояние |
|---|---|---|
| Idle | Получен запрос на подключение | WaitingForCAP |
| WaitingForCAP | Верификация CAP + обмен ключами завершены | SessionEstablished |
| WaitingForCAP | Сбой CAP / тайм-аут | Idle |
| SessionEstablished | Request_Frame инициирован или получен | Negotiating |
| SessionEstablished | Закрытие сессии по тайм-ауту | Idle |
| Negotiating | Соглашение достигнуто | Transmitting |
| Negotiating | Сбой переговоров / отклонение | SessionEstablished |
| Transmitting | Непрерывная передача Fragment | Transmitting |
| Transmitting | Динамическая корректировка соглашения | Negotiating |
| Transmitting | Разрыв соединения | Suspended |
| Transmitting | Соглашение завершено (нет других активных соглашений) | SessionEstablished |
| Suspended | Соединение восстановлено + повторная верификация CAP | Resuming |
| Suspended | Тайм-аут сессии | Idle |
| Resuming | Рукопожатие возобновления завершено | Transmitting |
| Resuming | Сбой восстановления | Idle |
3.4 Последовательность взаимодействия Master-Slave
Полное взаимодействие DTP состоит из пяти фаз:
Фаза 1: Предварительная обработка CAP
- CAP завершает верификацию личности и обмен ключами
Фаза 2: Установление сессии DTP
- Master инициирует установление сессии со slave, генерируя Session_ID
Фаза 3a: Переговоры о сборе данных (инициируется Master)
- Master отправляет Request_Frame (запрос на сбор данных)
- Slave отвечает Response_Frame (принято / отклонено / контрпредложение)
- Соглашение достигнуто, генерируется Agreement_ID
Фаза 3b: Переговоры об инъекции данных (инициируется Slave)
- Slave отправляет Request_Frame (запрос на инъекцию данных)
- Master отвечает Response_Frame (принято / отклонено / контрпредложение)
- Соглашение достигнуто, генерируется Agreement_ID
Фаза 4: Передача данных
- Slave → Master: Fragment (сбор данных, с Agreement_ID)
- Master → Slave: Fragment (инъекция данных, с Agreement_ID)
Фаза 5: Прерывание и восстановление соединения
- Разрыв соединения → Восстановление соединения (повторная верификация CAP) → Сообщение наивысшего полученного порядкового номера → Возобновление передачи с точки прерывания