Если клиент рассчитан на конкретный локальный порт, второй клиент на том же ПК не может занять порт или делит пакеты с первым.
Почему Два клиента пытаются открыть один и тот же локальный UDP-порт (принудительно делят его через опцию повторного использования) → Следствие ОС передаёт входящие пакеты только одному из сокетов или не гарантирует, какой из них получит пакет. Роутер и сервер тоже видят оба клиента под одним адресом → На экране Один клиент не получает пакеты мира: не видно NPC и других игроков, или случается дисконнект
Основной ответственный Команда разработки · Разработка клиента · Совместно Команда разработки · Разработка сервера
Команда разработки: задачи
Клиент: поручить выбор локального порта ОС (bind на порт 0). Сервер: различать соединения по сессионному токену, выданному каждому соединению.
На графике
Высоко только у некоторых · число принятых пакетов по клиентам
Где смотреть
На ПК игрока с двумя запущенными клиентами выполнить в командной строке netstat -ano -p udp и посмотреть, какие локальные UDP-порты открыл каждый игровой процесс (PID). На стороне сервера проверить, приходят ли две сессии с одного публичного IP и одного порта
Подтверждает
Два игровых процесса привязаны к одному локальному порту, или на сервере две сессии видны с одного IP и порта. С одним запущенным клиентом всё нормально
Опровергает
Если клиенты используют разные локальные порты, а с одним из них всё равно что-то не так, причина в ошибке разделения сессий по IP или устройству либо в ограничении на несколько клиентов
Чем проверить
Проверка на стороне игрока
Источники
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft При повторном bind на тот же порт с SO_REUSEADDR второй сокет перехватывает порт, и неизвестно, какой сокет получит пакет
bind function (winsock.h)Microsoft При bind на порт 0 выделяется уникальный порт из динамического диапазона (49152–65535)
netstatMicrosoft -a показывает порты TCP и UDP, -n выводит адреса в числовом виде, -o показывает ID процесса (PID), -p udp оставляет только UDP