We hit a repeatable stall in the native ICE client on Windows with GameNetworkingSockets 1.6.0.
When a STUN request times out, the client uses the server's address to find its position in the configured server list, then tries the next entry. If several entries have the same address, it keeps finding the first match and retrying the same next entry.
The client doesn't mark STUN discovery as failed, and the retries continue without a pause.
In our setup, stun.l.google.com and stun1.l.google.com through stun4.l.google.com all resolved to the same IPv4 and IPv6 addresses.
On a machine with an additional network adapter, sends through that adapter failed with WSAEADDRNOTAVAIL or WSAENETUNREACH. During match startup, the repeated retries caused the game to freeze.
We worked around it by configuring only STUN hostnames that resolve to distinct addresses. The keepalive path also appears to select servers by address, so duplicate entries may affect it as well.
We hit a repeatable stall in the native ICE client on Windows with GameNetworkingSockets 1.6.0.
When a STUN request times out, the client uses the server's address to find its position in the configured server list, then tries the next entry. If several entries have the same address, it keeps finding the first match and retrying the same next entry.
The client doesn't mark STUN discovery as failed, and the retries continue without a pause.
In our setup,
stun.l.google.comandstun1.l.google.comthroughstun4.l.google.comall resolved to the same IPv4 and IPv6 addresses.On a machine with an additional network adapter, sends through that adapter failed with
WSAEADDRNOTAVAILorWSAENETUNREACH. During match startup, the repeated retries caused the game to freeze.We worked around it by configuring only STUN hostnames that resolve to distinct addresses. The keepalive path also appears to select servers by address, so duplicate entries may affect it as well.