Надёжные и ненадёжные игровые сообщения: выбирать гарантии по смыслу

Классифицировать последствия потери

Надёжный режим транспорта повторно отправляет недостающие данные, пока соединение остаётся работоспособным; при ненадёжной доставке сообщения могут теряться. Порядок — отдельное свойство, которое API может сочетать с надёжностью. Выбирайте гарантии по смыслу сообщения: новый полный снимок положения может заменить старый, а запрос покупки требует определённого результата принятия или отказа. Ни одна категория не определяет, должен ли сервер доверять содержимому.

Отделить подтверждение пакета от результата действия

Номера последовательности идентифицируют пакеты или сообщения в пределах определённого потока. Подтверждение пакета означает, что транспортные данные прибыли; оно не доказывает, что игра проверила или выполнила действие. Разбор протокола Фидлером также объясняет, почему отсутствие подтверждений создаёт неопределённость и почему повторяемым данным приложения нужна собственная идентичность. [1]

Назначайте важным командам идентификатор с определённой областью действия и возвращайте результат приложения. Если повторные попытки или восстановление после переподключения могут повторить команду, сохраняйте её результат на весь поддерживаемый интервал повторов. Согласованно проверяйте запрос и фиксируйте его эффект и результат для устранения дубликатов. Надёжный сокет сам по себе не обеспечивает выполнение ровно один раз при сбоях процесса.

Пример: старое состояние и повторная команда

Пусть полное состояние движения 41 помещает аватар в координату 8, а состояние 42 — в координату 9. Если 42 приходит раньше 41, получатель, ориентированный на свежесть, сохраняет координату 9 и отбрасывает старое состояние. Такая политика требует самодостаточных обновлений или действительной базы для восстановления; отбрасывание произвольных дельт может нарушить восстановление состояния.

Независимо от этого клиент отправляет команду 17 на подбор предмета. Сервер проверяет её, выдаёт предмет и записывает результат. Если команда 17 повторяется из-за потери ответа приложения, сервер возвращает записанный результат без выдачи ещё одного предмета. Идентификатор команды и последовательность движения решают разные задачи и не должны случайно получать общую семантику.

Изолировать зависимости порядка и ограничивать трафик

Надёжная упорядоченная доставка может задерживать последующие сообщения из-за отсутствующего более раннего сообщения в том же потоке. Каналы соединения Valve позволяют независимому трафику не разделять такую зависимость: надёжные сообщения упорядочены внутри канала, но соответствующей гарантии между каналами нет. Никогда не разделяйте причинно зависимые операции по каналам без явной обработки зависимости. [2]

Отделяйте кратковременное состояние от объёмных передач, если транспорт это поддерживает. Ограничивайте очереди отправки, отслеживайте возраст сообщений и позволяйте управлению перегрузкой задавать темп передачи. Постоянная постановка устаревающих состояний в очередь надёжной доставки может наращивать задержку, даже если последующая доставка работает. Объединяйте или заменяйте ещё не отправленное состояние только там, где это допускает его смысл.

Проверить договорённости о доставке

Искусственно создавайте потери, дублирование, перестановку и разрывы связи. Проверяйте отклонение старого состояния, устранение повторных команд, пределы очередей и восстановление после переподключения. Определите область идентификаторов, обработку переполнения последовательности и срок хранения результатов. Надёжность не делает просроченную команду полезной, не разрешает недопустимый запрос и не гарантирует завершения после окончательного разрыва связи. Передавайте игровой логике состояния ожидания, подтверждения и отказа там, где эти различия существенны.

Источники

• [1] Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games.
• [2] GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, original API source.