ConfigureConnectionLanes: reconfiguring lanes can leave one lane in a stale priority class

Abierto
  • ¿Algo no está bien?
#453 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@sebxt ya está trabajando en esto.

Desde el 20/10/2026.

  • #454 de @sebxt — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
networking

Línea de trabajo

Read CSteamNetworkConnectionBase::SNP_ConfigureLanes in steamnetworkingsockets_snp.cpp, focusing on the loop that merges sorted priority classes and assigns m_idxPriorityClass. Reproduce by swapping lane priorities, then check lane status; also try priorities {0, 1, 2} followed by {1, 1, 0} to expose the out-of-bounds case. Done means every lane's class matches the current priorities after each configuration; linked PR #454 is already open.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happens

The docs for ConfigureConnectionLanes say lanes may be reconfigured at any time. When a connection reconfigures its lanes, the lane with the lowest priority value (the one that sorts first) keeps whatever m_idxPriorityClass it had from the previous configuration. Every other lane gets its class index reassigned.

Swapping priorities on two lanes is enough to see it. Lane 1 should now be strictly ahead of lane 0, but it stays in class 1 next to lane 0. Class 0 ends up with no lanes, and the two lanes share bandwidth by weight instead of by priority.

If the stale index is greater than or equal to the new number of priority classes, m_vecPriorityClasses[ l.m_idxPriorityClass ] in the "Setup each lane" loop reads past the end of the vector. For example: priorities { 0, 1, 2 }, then { 1, 1, 0 }. Lane 2 keeps class 2, but there are now only 2 classes.

What should happen

After every call, each lane's priority class should match the priorities passed to that call.

Minimal repro

// hSender from CreateSocketPair( ..., true, ... ), fixed send rate of 128 KB/s
int prio1[2] = { 0, 1 };
ConfigureConnectionLanes( hSender, 2, prio1, nullptr );
int prio2[2] = { 1, 0 };
ConfigureConnectionLanes( hSender, 2, prio2, nullptr );
// queue 64 KB of unreliable messages on each lane, then:
GetConnectionRealTimeStatus( hSender, &status, 2, laneStatus );

Expected: lane 1 queue time is about 500 ms and lane 0 is about 1000 ms.
Actual: both lanes report 1000 ms, because they are scheduled in the same class.

Root cause

In CSteamNetworkConnectionBase::SNP_ConfigureLanes (steamnetworkingsockets_snp.cpp), the loop that merges sorted priority classes starts at j = 1 and only assigns m_idxPriorityClass for pPriorityClass[j]. The entry at sorted position 0 is never assigned. On the first configuration this goes unnoticed, because a newly created lane defaults to class 0. On a later reconfiguration, that lane may already exist with a nonzero class.

Lenguaje dominante
C++
Estrellas
10k
Forks
767
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ValveSoftware/GameNetworkingSockets

Todos los issues de ValveSoftware/GameNetworkingSockets

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.