한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Анатомия игровых лагов › Проблемы только у части игроков

Потеря данных о появлении из-за наплыва сразу после входа Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

ID причины pt-spawn-burst · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента

Открыть карточку в основной версии с иллюстрациями и экспериментами →

В момент входа в зону сервер разом отправляет данные о появлении десятков и сотен окружающих объектов. Если отправлять их по ненадёжному каналу доставки (unreliable) или если буфер приёма переполнится, пока клиент занят загрузкой и не читает сокет, часть данных пропадает и повторно не приходит.

Почему Сразу после входа данные о появлении приходят плотной пачкой за короткое время → Следствие Клиент во время загрузки поздно читает сокет, и буфер приёма ОС переполняется, или большой UDP-пакет фрагментируется, и при потере одного фрагмента пропадает целиком. По ненадёжному каналу доставки повторной отправки нет → На экране Только в клиенте с медленной загрузкой не хватает нескольких NPC. Если выйти из зоны видимости и вернуться, они видны

Симптомы
Невидимки / фантомы
Факторы
Потери
У кого
Один из клиентов на одном ПК, Только у меня
Когда
Сразу после входа или техработ, В движении и при смене локации
Ответственные
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента
Команда разработки: задачи
Сервер: уведомления о появлении и исчезновении отправлять только по надёжному каналу с гарантированной повторной передачей, начальные данные отправлять частями. Клиент: принимать данные в отдельном от загрузки потоке, увеличить буфер приёма.
Цифры для ориентира
Стандартный размер буфера приёма UDP на ПК зависит от ОС, но обычно составляет от десятков до сотен KB. Если данных о входе в людный город больше, буфер переполняется, даже если загрузка лишь ненадолго мешает читать сокет.
На графике
Всплеск сразу после входа или техработ · объём приёма сразу после входа, число пропущенных уведомлений о появлении
Где смотреть
Сравнить число уведомлений о появлении, отправленных сервером сразу после входа, с числом полученных клиентом и посмотреть, по какому каналу (надёжному или ненадёжному) они шли. В захвате пакетов на стороне сервера смотреть объём, ушедший этому игроку сразу после входа, и фрагментированные пакеты (фильтр Wireshark ip.flags.mf == 1 || ip.frag_offset > 0)
Подтверждает
Получено меньше, чем отправлено, пропуски собраны на участке плотной пачки сразу после входа, а отправка шла по ненадёжному каналу или большие пакеты фрагментированы. Чаще бывает в клиенте с медленной загрузкой
Опровергает
Если отправлено и получено одинаково, а NPC не видно, данные отброшены после получения (отбрасывание уведомлений о появлении во время загрузки) или проблема в расчёте зоны видимости. Если пропуски бывают в любое время, независимо от входа, это потери на линии связи
Чем проверить
Нужны логи и метрики игрового сервера или клиента

Источники

  1. RFC 8085: UDP Usage Guidelines IETF
    Фрагментированный пакет пропадает целиком при потере любого одного фрагмента
  2. UDP vs. TCP Gaffer On Games
    UDP не гарантирует ни доставку, ни порядок, поэтому потерянные пакеты нужно обнаруживать и отправлять повторно самостоятельно
  3. Socket.ReceiveBufferSize Property Microsoft
    Стандартный размер буфера приёма сокета зависит от ОС
  4. Display Filter Reference: Internet Protocol Version 4 Wireshark
    Фрагментированные IP-пакеты отбираются по ip.flags.mf (More fragments) и ip.frag_offset (Fragment Offset)

Смотрите также

Тот же слой: Проблемы только у части игроков

Причины с тем же симптомом (Невидимки / фантомы) на других слоях

Карточка в основной версии с иллюстрациями и экспериментами