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

Ouverte
  • Quelque chose ne va pas ?
#453 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@sebxt y travaille déjà.

Depuis le 20/10/2026.

  • #454 par @sebxt — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
cpp
Domaine
networking

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C++
Étoiles
10k
Forks
767
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ValveSoftware/GameNetworkingSockets

Toutes les issues de ValveSoftware/GameNetworkingSockets

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.