Если собственные правила повторной передачи поверх UDP слишком осторожные, потери восстанавливаются поздно, а если слишком агрессивные, они ещё сильнее забивают линию.
Почему Интервал повторов, их число и размер окна не соответствуют качеству подключения → Следствие Восстановление запаздывает, либо дублирующие передачи усиливают перегрузку → На экране Умения «съедаются», перемотка, при перегрузке лаги сильнее
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: повторно передавать по измеренному RTT, разделить каналы доставки по важности данных. Клиент: применить те же настройки повторной передачи и каналов, что и на сервере.
На графике
Случайные всплески · доля повторных передач надёжного UDP, RTT внутри игры
Где смотреть
Логировать на сервере и клиенте статистику, которую используемая библиотека ведёт по каждому соединению (число повторных передач, оценка RTT, ожидание перед повтором), и сравнить с реальной долей потерь на подключении того же игрока (измеренной mtr)
Подтверждает
Если доля повторных передач в разы выше реальной доли потерь, настройки слишком агрессивные. Если ожидание перед повтором в разы больше измеренного RTT, слишком осторожные
Опровергает
Если доля повторных передач близка к доле потерь, а ожидание соответствует RTT, с настройками всё в порядке. Смотреть сами потери на подключении
Чем проверить
Нужны логи и метрики игрового сервера или клиента
Источники
RFC 8085: UDP Usage GuidelinesIETF Повторные передачи могут усиливать перегрузку, поэтому на них распространяется управление перегрузкой. RTT оценивают как среднее по нескольким измерениям (EWMA), начальное значение 1 секунда, при срабатывании таймера скорость передачи снижают