Allocation des serveurs
L'allocation de serveur est l'étape au cours de laquelle une partie prête est associée à une instance de serveur de jeu spécifique dans un lieu spécifique. Le système de matchmaking décide qui joue ensemble ; l'allocation décide d'où ils jouent. Si vous vous trompez, un groupe parfaitement assorti jouera avec une latence évitable.
Aussi appelé
allocation
,
Où se situe l'allocation de serveur dans le cycle de vie d'un match ?
L'allocation est le passage de relais entre deux systèmes. Le travail du matchmaker se termine lorsqu'il dispose d'un groupe de joueurs. Le travail de l'infrastructure commence lorsque ce groupe a besoin d'un endroit pour jouer.
Le match se forme. Le matchmaker se décide sur les joueurs, le mode et souvent la carte.
La demande est envoyée. Elle transporte ce dont le placement a besoin : les joueurs, leurs adresses IP ou les latences mesurées, et la version de build exécutée par leurs clients.
Un serveur est attribué au match. Soit un serveur déjà en cours d'exécution est réservé, soit un nouveau est démarré pour l'occasion.
Le serveur prend connaissance de son match. L'ID du match, les équipes et les joueurs attendus parviennent au serveur, afin qu'il sache qui admettre et quoi charger.
Les joueurs reçoivent une adresse. Chaque client reçoit l'adresse IP ou le nom d'hôte et le port du serveur, puis s'y connecte.
Le serveur est libéré à la fin du match, soit renvoyé vers un pool, soit arrêté.
Les étapes 2 à 5 prennent souvent quelques secondes, passées sur un écran de matchmaking. Avec la latence qu'elle détermine, cette attente fait de l'allocation la partie de l'infrastructure que les joueurs ressentent le plus.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
La sélection de la région est une plainte des joueurs, pas une demande de fonctionnalité : lorsque les joueurs demandent à choisir la région de leur serveur, ils signalent un problème de latence qu'ils ne peuvent ni voir ni contrôler. La fonctionnalité qu'ils demandent est une réponse possible, et sur une base de joueurs plus restreinte, elle échange de mauvaises parties contre des parties non remplies.
Le regroupement basé sur la latence résout le problème que le verrouillage régional tente d'atténuer : les régions sont des frontières administratives. La latence est mesurée. Le fait de regrouper les joueurs par ping mesuré permet de garder les joueurs éloignés en dehors du même salon sans diviser la file d'attente par zone géographique.
L'assouplissement des règles au fil du temps est le levier que la plupart des systèmes de matchmaking sous-utilisent : les recherches publiées par Activision révèlent que les contraintes de niveau de jeu sont assouplies plus rapidement que les contraintes de connexion à mesure que le temps d'attente augmente. La même approche progressive s'applique à toute règle de regroupement.
Le temps d'attente est négociable lorsque le compromis est visible : les joueurs de plusieurs communautés acceptent volontairement d'attendre plus longtemps pour une meilleure connexion ou une partie plus remplie. L'attente n'est pas ce qui les frustre. C'est le fait de ne pas savoir ce qu'elle leur apporte qui les dérange.
La transparence et la capacité d'action raccourcissent la boucle de rétroaction : un indicateur de ping visible et la possibilité de choisir d'attendre un serveur plus proche transforment un blâme vague en quelque chose sur lequel le joueur peut agir, au prix de révéler des chiffres que vous ne souhaiteriez peut-être pas divulguer.
Réclamer un serveur prêt ou en démarrer un nouveau ?
Il existe deux façons de réaliser l'étape 3, et la différence majeure entre elles n'est pas la vitesse. Il s'agit du moment où l'emplacement est déterminé.
Réclamer un serveur prêt. Un pool de serveurs est déjà en cours d'exécution, chacun étant en attente dans un état prêt. L'allocation en marque un comme pris et fournit son adresse. L'emplacement a été fixé au moment où le pool a été rempli, avant que l'un de ces joueurs ne rejoigne la file d'attente.
Démarrer un serveur pour le match. Rien n'est en attente. L'allocation choisit un emplacement pour ce groupe et y démarre un serveur, de sorte que le temps nécessaire correspond au démarrage à froid du serveur. L'emplacement est choisi après que les joueurs sont connus.
La réclamation semble instantanée tant que le pool contient des serveurs au bon endroit. Lorsqu'il s'épuise, ou s'il les contient dans la mauvaise ville pour ce groupe, le match attend un réapprovisionnement ou se joue dans un endroit moins adapté. La section Pools chauds traite du coût de maintien de cette capacité.
Connaître les joueurs modifie également la signification du « bon endroit » : le placement pour un groupe prend en compte la latence de chaque joueur, et pas seulement celle du premier (la section régions de serveurs compare cela avec l'attribution d'une région au préalable).
Pourquoi l'allocation de serveur échoue-t-elle ?
Les joueurs connaissent cette étape par son message d'erreur. L'erreur "Échec de l'allocation du serveur" apparaît assez souvent dans des jeux comme Gears 5 et Forza Motorsport pour que les joueurs la recherchent. Derrière ce message, les causes sont généralement peu nombreuses :
Aucune capacité là où la demande a été faite. Le pool pour cet emplacement est vide, ou l'emplacement n'a pas de place pour un nouveau serveur.
Aucun serveur n'exécute la version du match. Le jour du déploiement d'un correctif, un client sur la nouvelle version a besoin d'un serveur sur la nouvelle version, et inversement. Tant que les deux côtés de la mise à jour n'ont pas de capacité disponible, certaines demandes n'ont nulle part où aller.
Le serveur n'a pas été prêt à temps. Une image volumineuse qui n'est pas mise en cache sur l'hôte, ou un démarrage de jeu lent, peut dépasser le délai d'expiration de la demande.
Un flux d'allocation bien conçu traite l'échec comme une branche normale plutôt que comme une exception. Il effectue un nombre limité de tentatives, se replie sur un autre emplacement ou fournisseur, et conserve la place des joueurs dans la file d'attente au lieu de les renvoyer au début. Les clients réessayent également la connexion pendant une courte fenêtre de temps, car une adresse peut arriver alors que le serveur est encore en cours de démarrage.
Les joueurs peuvent-ils être affectés à un serveur déjà en cours d'exécution ?
L'allocation n'est pas uniquement réservée aux nouveaux matchs. Les cas suivants envoient les joueurs vers un serveur qui est déjà en cours d'exécution :
Le backfill remplit les places qui se libèrent en milieu de partie lorsqu'un joueur s'en va. Le serveur en cours d'exécution demande des joueurs au matchmaker, ce qui inverse le sens habituel de la requête.
Les serveurs multi-salles hébergent de nombreux petits matchs dans un seul processus, de sorte qu'un nouveau match se voit attribuer une salle plutôt qu'un serveur entier.
Les sessions par place, courantes dans les hubs sociaux et les mondes persistants, attribuent une place à un joueur sur un serveur jusqu'à ce qu'il parte.
Dans chaque cas, l'allocateur suit la capacité à l'intérieur des serveurs, et pas seulement les serveurs eux-mêmes. Un serveur disposant de deux places libres peut accueillir un groupe de deux personnes, mais pas de trois. Cette comptabilité détermine donc le taux de remplissage réel des serveurs, et par conséquent le taux de remplissage des sessions.
Un mot de notre sponsor (nous-mêmes !)
Le jour du lancement est un bien mauvais moment pour découvrir les cas limites d'un orchestrateur. L'orchestration automatisée d'Edgegap a géré 135 millions de déploiements de serveurs de jeux depuis février 2019 à travers son réseau multi-cloud distribué, et déploie aujourd'hui quotidiennement pour le compte de milliers de jeux et de plusieurs millions de joueurs.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
N'oubliez pas de planifier pour l'échec de l'allocation
La plupart des chiffres d'allocation suivis par les équipes décrivent les allocations qui ont fonctionné : la rapidité avec laquelle un serveur a démarré, la vitesse à laquelle un pool en a attribué une. Les joueurs subissent également celles qui ont échoué.
Décidez donc avant le lancement de ce qui se passe pour chaque échec dans la section « Why Does Server Allocation Fail? » (Pourquoi l'allocation de serveur échoue-t-elle ?) : combien de tentatives, quel emplacement ou fournisseur vient ensuite, si les joueurs conservent leur place dans la file d'attente et ce qu'ils voient pendant que cela se produit. Mesurez ensuite la part des matchs formés qui se terminent avec chaque joueur connecté, au plus fort de l'activité plutôt qu'en moyenne. Si personne ne peut produire ce chiffre, c'est que le parcours d'échec n'a pas encore été testé.
Les données de la plateforme d'Edgegap recensent 135 millions de déploiements depuis février 2019, y compris ceux qui n'ont pas démarré (données de la plateforme, 18 septembre 2026). La solution de secours (fallback) doit également avoir un endroit où aller : Edgegap couvre plus de 615 emplacements répartis sur plus de 17 fournisseurs, avec un basculement automatique entre eux.
,
