Соединение клиентского сокета начинает работать только после проверки связи с сервером?
У меня есть сетевая игра, которую я тестирую в локальной сети. Я использую RakNet в качестве сетевой библиотеки.
Как правило, все работает нормально, но иногда кажется, что клиент (iPhone) «запутался» при инициации подключения к серверу (Macbook в той же локальной сети - оба подключены по беспроводной сети).
После подключения клиента все работает нормально. Он будет поддерживать соединение бесконечно. Но иногда призыв к connect() просто сидит и крутится и, кажется, никогда никуда не денется, даже примерно через 30 секунд. Я начну получать сообщения «Нет маршрута к хосту» и «Хост не работает» на стороне клиента.
Я обнаружил, что в течение этого периода ожидания, который не разрешится сам по себе, если я инициирую пинг с сервера (Macbook) на клиент (iPhone), клиент немедленно подключится. Ожидание может занять 28 секунд, и как только я попытаюсь его пропинговать, все разрешится.
В периоды, когда соединение не работает, я также обнаружил, что попытка пинговать с iPhone на Macbook не работает.
Это похоже на проблему с маршрутизатором? Это действительно прерывисто - все будет нормально работать в течение нескольких минут, а затем я могу многократно воспроизводить невозможность подключения. Затем я пингую клиента, и все снова работает.
Это невероятно расстраивает, и мне бы хотелось получить советы о том, что может вызывать проблемы!
ОБНОВЛЕНИЕ 1
@PedroPerez прокомментировал, что это может быть связано с проблемой ARP. Чтобы попытаться получить некоторые данные об этом, я провел следующие тесты в беспорядочном режиме и попытался найти пакеты ARP, на которые можно посмотреть:
- WireShark работает на Macbook (сервер)
- WireShark работает на iPhone (клиент)
При захвате данных на сервере я обнаружил, что каждые 20-50 секунд я видел пару вызовов ARP с маршрутизатором, запрашивающим MAC-адрес IP-адреса сервера, с последующим немедленным ответом. Каждые 70 секунд мой Macbook (сервер) будет запрашивать MAC-адрес моего Apple TV. Это было для «устойчивого состояния» ARP-трафика на сервере. Он будет повторяться, как часы. Вот скриншот:
При захвате данных через виртуальный интерфейс на клиенте (который я создал с помощью вызова rvictl в терминале) картина была немного более мутной. Во-первых, по какой-то причине пакеты ARP не проходили в WireShark как пакеты ARP, хотя их содержимое было таким же (42 байта). Они просто появились как «Необработанные пакетные данные». Изучив содержимое необработанных пакетов, я мог видеть, что каждые пять секунд (кажется чрезмерным ?!) iPhone (клиент) получал ответный пакет ARP (казалось бы, незапрашиваемый?) От маршрутизатора, давая ему правильный IP-адрес. Я не уверен, почему частота такая высокая или почему маршрутизатор отправляет ответы без запросов. Вот скриншот этого процесса.
Мне также удалось захватить ARP-пакеты в течение этого чрезвычайно длительного периода тайм-аута, и я заметил, что непосредственно перед установкой соединения (после ожидания в течение 20-30 секунд) один из (вероятно, «устойчивых») широковещательных пакетов выходит из Macbook запрашивает (совершенно не связанный!) MAC-адрес Apple TV. Однако транслируемый запрос от Macbook включает в себя его IP и MAC-адрес, поэтому, возможно, поскольку клиент iPhone может «слышать» этот транслируемый запрос, он обновляет свою таблицу ARP, как только видит этот запрос? Но тогда почему он снова об этом забывает?