Native ICE STUN failover can stall when server entries share an address
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- networking
- Área
- networking
Línea de trabajo
Look at the native ICE client code, likely in files handling STUN server lists and failover logic. The issue describes a loop when duplicate addresses exist in the server list. Start by finding where STUN requests are made and how the next server is selected after a timeout. Check for address-based indexing. The fix involves ensuring unique address selection or marking discovery as failed. Test with a setup using duplicate hostname entries.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C++
- Estrellas
- 9.9k
- Forks
- 749
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ValveSoftware/GameNetworkingSockets
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Feature Request: Player Region Filtering and Maximum Latency Preference for Steam Networking Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
TSan: data race on the unsynchronized static FILE* lazy init in Plat_IsInDebugSession (Linux) Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
ValveSoftware/GameNetworkingSockets#425 · 7 comentarios ·
Todos los issues de ValveSoftware/GameNetworkingSockets
Issues similares
-
Code path without return value Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
drogonframework/drogon#2605 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
ArthurSonzogni/FTXUI#1363 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 94/100
MiSTer-devel/Main_MiSTer#1325 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100