Глава 8: Надёжность

8.1 Механизм возобновления

DTP реализует механизм возобновления на основе порядковых номеров, обеспечивая полную передачу данных в нестабильных сетевых средах.

Основная цель: при возобновлении передачи после разрыва соединения нет необходимости повторно отправлять данные, которые уже были успешно получены.

Принцип работы

Sender                              Receiver
  │                                   │
  │── Fragment (seq=1) ──────────────▶│ ✓ Получен
  │── Fragment (seq=2) ──────────────▶│ ✓ Получен
  │── Fragment (seq=3) ──────────────▶│ ✓ Получен
  │── Fragment (seq=4) ────── ✗ ──────│ Соединение потеряно
  │                                   │
  │     ... Соединение восстановлено ...│
  │                                   │
  │◀── Сообщение наивысшего полученного seq (3)│
  │                                   │
  │── Fragment (seq=4) ──────────────▶│ Возобновление с точки прерывания
  │── Fragment (seq=5) ──────────────▶│
  │                                   │

Обязанности отправителя

1. Назначать каждому Fragment монотонно возрастающий порядковый номер
2. Кэшировать локально Fragment, ещё не подтверждённые получателем
3. При получении подтверждения удалять подтверждённые Fragment из кэша
4. После восстановления соединения возобновлять передачу, начиная с Fragment, следующего за наивысшим порядковым номером, сообщённым получателем

Обязанности получателя

1. Отслеживать наивысший успешно полученный порядковый номер
2. При восстановлении соединения сообщать отправителю наивысший успешно полученный порядковый номер

8.2 Управление кэшем

Отправитель поддерживает локальный кэш неподтверждённых Fragment:

• Каждый Fragment, который был отправлен, но ещё не подтверждён, сохраняется в кэше
• При получении подтверждения подтверждённые Fragment удаляются из кэша
• Кэш имеет ограничение по ёмкости

Обработка переполнения кэша

Когда локальный кэш отправителя достигает предела ёмкости:

1. Приостановить отправку новых Fragment
2. Уведомить приложение верхнего уровня о переполнении кэша
3. Дождаться подтверждения от получателя для освобождения места в кэше перед возобновлением передачи

8.3 Управление сессиями

Установление сессии

После завершения CAP верификации личности и обмена ключами DTP_Engine устанавливает сессию DTP и генерирует уникальный идентификатор сессии (Session_ID).

Поддержание состояния сессии

DTP_Engine поддерживает двунаправленное состояние передачи в рамках сессии:

Элемент состояния	Описание
currentSequenceNumber	Текущий порядковый номер
highestAcknowledgedSequenceNumber	Наивысший подтверждённый порядковый номер
unacknowledgedFragmentCache	Кэш неподтверждённых Fragment
activeAgreements	Список активных соглашений

Каждое направление (сбор и инъекция) поддерживает независимое состояние передачи.

Персистентность сессии

При разрыве нижележащего транспортного соединения DTP_Engine сохраняет состояние сессии (включая все активные соглашения) в хранилище для поддержки последующего восстановления соединения.

Восстановление сессии

После восстановления соединения и прохождения повторной верификации CAP DTP_Engine восстанавливает предыдущее состояние сессии (включая активные соглашения) и возобновляет передачу.

Процесс восстановления:

1. Нижележащее соединение восстановлено
2. CAP повторно верифицирует личность
3. DTP_Engine восстанавливает состояние сессии из персистентного хранилища
4. Получатель сообщает наивысший полученный порядковый номер
5. Отправитель возобновляет передачу с точки прерывания

Тайм-аут сессии

Если сессия остаётся неактивной сверх настроенного протоколом порога тайм-аута, DTP_Engine закрывает сессию и освобождает связанные ресурсы. После тайм-аута необходимо установить новую сессию.

8.4 Механизм повторной передачи

Когда отправитель не получает подтверждение от получателя в течение настроенного протоколом периода тайм-аута повторной передачи, он автоматически повторно передаёт неподтверждённые Fragment.

Стратегия повторной передачи:

1. Ожидание настроенного периода тайм-аута
2. Повторная передача неподтверждённых Fragment после тайм-аута
3. Если количество повторных передач превышает порог, уведомить приложение верхнего уровня о сбое передачи

8.5 Типичные сценарии

Сценарий 1: Тоннель метро

Телефон пользователя теряет сетевое подключение в тоннеле метро, загрузив 300 из 500 записей данных о тренировке. После выхода из тоннеля и восстановления связи DTP возобновляет передачу с записи 301 без повторной отправки первых 300.

Сценарий 2: Выход за пределы зоны Bluetooth

Умные часы пользователя теряют Bluetooth-соединение с телефоном из-за чрезмерного расстояния. Когда пользователь возвращается в зону действия, соединение автоматически восстанавливается, и часы продолжают загрузку данных о пульсе, накопленных за время отключения.

Сценарий 3: Перезапуск сервера

Экземпляр FayGer, на котором работает iFay, перезапускается; состояние сессии DTP было сохранено. После перезапуска сессия восстанавливается и приём данных от терминала продолжается с точки прерывания.