Navigateur de serveurs
Bienvenue dans la BÊTA OUVERTE d’Edgegap Server Browser. Nous espérons que vous apprécierez l’opportunité de prévisualiser notre nouveau service et d’aider à façonner son avenir grâce à des discussions de table ronde sur notre Discord.
Server Browser est un service géré pour les serveurs Match-Bound et persistants :
aider les joueurs à rechercher et rejoindre des serveurs adaptés en fonction de la capacité, de la latence ou des paramètres de jeu ;
pré-chauffer de nouveaux serveurs pour servir des audiences mondiales à grande échelle et éviter des files d’attente frustrantes ;
rationaliser les opérations des serveurs y compris les mises à jour, redémarrages, la persistance, le maillage, et plus encore.
Vous cherchez à associer des joueurs selon des règles strictes, sans permettre le choix du serveur ? Envisagez Appariement.

✔️ Préparation
Flux et hiérarchie

Server Browser offre deux fonctionnalités principales :
Navigateur de serveurs avec les clients de jeu pour :
Découvrir et trouver des instances de serveur adaptées, voir les emplacements et réserver la capacité disponible.
Réserver des places dans un emplacement d’instance, récupérer les détails de connexion et se connecter aux serveurs.
Authentifier les connexions des joueurs depuis les déploiements en utilisant l’identité fédérée.
Mettre à jour la capacité disponible et/ou les métadonnées des emplacements d’instance afin de modifier les critères de découverte.
Navigateur de serveurs (optionnel) avec les politiques de mise à l’échelle pour :
Surveiller les instances de serveur disponibles, les emplacements, la capacité — par région et/ou selon d’autres critères.
Déployer des serveurs pour augmenter la capacité avec le préchauffage ou la mise à l’échelle juste à temps.
Automatiser les opérations avec des politiques spéciales pour les démos, mises à jour, tests, AQ, tournois, et plus encore.
Après la sortie, votre navigateur de serveurs devra fonctionner 24 h/24 et 7 j/7 pour garantir que les joueurs du monde entier puissent rejoindre des serveurs.
▶️ Commencer la navigation
Découvrez le cycle de vie serveur/joueur et leurs responsabilités afin d’assurer une utilisation efficace des serveurs.
Authentifier
Server Browser génère automatiquement deux types de jetons :
Jeton serveur - requis pour les méthodes de l’API serveur , peut être injecté comme variable de version d’application.
Accorde l’accès à toutes les méthodes d’API, et est pratique pour les tests, le devops ou l’orchestration personnalisée.
Jeton client - requis pour les méthodes de API Monitor et API de réservation de places utilisé par les clients de jeu.
Nous recommandons de stocker ce jeton dans un gestionnaire de secrets tiers afin de faciliter la rotation des jetons.
Découvrir une instance
Nouveau Déploiements doit créer une nouvelle instance avec au moins un emplacement lors de son initialisation.
Voir Navigateur de serveurs pour en savoir plus sur les politiques de mise à l’échelle et démarrer les déploiements automatiquement.
Paramètres de métadonnées personnalisés optionnels pour le filtrage, le tri et la navigation des joueurs.
Exemples :
informations d’emplacement - capacité d’équipe et métadonnées spécifiques à l’équipe (p. ex. nom de l’équipe),
nom et tags - étiquettes personnalisables, uniques, lisibles par des humains et consultables ;
détails de connexion - URL, IP, ports externes ou autres paramètres ;
données de compatibilité - version du serveur ou versions client prises en charge ;
qualificateurs de latence - identifiants de ville et de région, et Balises Ping détails ;
paramètres de jeu - niveau/scène/carte, mode de jeu, difficulté, mods utilisés ;
tout autre paramètre personnalisé pour aider les joueurs à filtrer et trouver un serveur adapté.
Les paramètres de métadonnées ci-dessus ne sont que des exemples, vous pouvez définir n’importe quels paramètres, y compris ceux ci-dessus. Tous les paramètres de métadonnées sont optionnels, et certaines instances peuvent ne pas avoir besoin de définir tous les paramètres.
Les métadonnées prennent en charge des clés de type chaîne et des valeurs contenant une chaîne, un nombre, un booléen ou un tableau de chaînes.
Pour sérialiser des objets imbriqués, essayez d’encoder leur chemin d’accès dans la clé comme "object.child.property".
Les serveurs peuvent mettre à jour les métadonnées de l’instance ou de l’emplacement à tout moment pour modifier leurs critères de découvrabilité.
Les instances de serveur doivent envoyer périodiquement un heartbeat keep-alive pour vérifier leur disponibilité continue et empêcher les joueurs de rejoindre des serveurs plantés ou hors ligne. L’absence de heartbeat pendant la période d’expiration configurée supprimera automatiquement l’instance et toute réservation de place en attente.
Voir Persistance pour gérer l’état persistant du monde et Applications et versions pour des déploiements plus rapides.
Rechercher et parcourir
Les joueurs peuvent lister les instances de serveur et paginer à travers les résultats pour trouver un serveur qu’ils souhaitent rejoindre. Pour afficher les données de ping (latence), lisez les Balises Ping détails de chaque instance et mesurez la latence.
Les instances et les emplacements peuvent être filtrés par places rejoignables ou paramètres de métadonnées indexés.
"joinable_seats"
eq ou ne ou
lt ou le ou
gt ou ge
"string"
(métadonnées)
eq ou ne ou
lt ou le ou
gt ou ge ou
contient
"int" , ou "float"
(métadonnées)
eq ou ne ou
lt ou le ou
gt ou ge
"bool"
(métadonnées)
eq ou ne
Filtrez par régions et/ou villes pour restreindre la sélection avant de mesurer la latence vers les serveurs.
Découvrez la Pagination basée sur un curseur pour permettre aux utilisateurs de récupérer plus de résultats.
Réserver des places
Avant de rejoindre un serveur, une réservation de place est requise pour s’assurer que l’instance offre une capacité disponible suffisante. Les réservations peuvent inclure un groupe de joueurs ou une personne seule.
Les réservations dépassant la capacité de places rejoignables de l’emplacement seront automatiquement rejetées (409 Conflit). Les places rejoignables sont toutes les places disponibles qui n’ont pas encore été réservées par d’autres joueurs.
Identité fédérée : les joueurs doivent fournir un identifiant de joueur tiers unique dans leur réservation. Envoyer le même identifiant une fois qu’ils Navigateur de serveurs permettra au serveur de vérifier leur identité.
Une fois qu’une réservation est effectuée avec succès (200 OK) les joueurs doivent tenter de se connecter immédiatement. Les réservations expireront après 30 secondes à moins qu’elles ne soient confirmées par votre serveur.
Le serveur peut modifier de force la capacité de n’importe quel emplacement, ajouter, supprimer ou mettre à jour n’importe quels emplacements. Toutes les réservations pour un emplacement donné seront supprimées si des réservations en attente dépassent la nouvelle capacité disponible de l’emplacement.
Se connecter au serveur
Une fois qu’un joueur a trouvé une instance adaptée, il peut récupérer les détails de connexion requis depuis les métadonnées (URL, IP, Port externe). Dès que la réservation de place est effectuée, les joueurs peuvent continuer et se connecter au serveur de jeu de votre déploiement et transmettre leur identifiant de joueur.
Pour vous connecter depuis PIE (Éditeur) pendant le développement et les tests, appuyez sur la touche tilde ~ et tapez open {URL}:{port} et attendez que votre éditeur charge la carte.
En cas d’échec de connexion ou d’écran noir, consultez notre guide de dépannage.
Pour connecter votre éditeur Unity ou client de jeu à votre déploiement cloud, saisissez :
Déploiement URL pointant vers l’IP du serveur, généralement dans le composant
NetworkManager.Port externe correspondant au port d’écoute interne du serveur, généralement dans un composant Transport.
En cas d’expiration de délai de connexion ou d’autres problèmes, consultez notre guide de dépannage.
Pour authentifier les nouvelles connexions, votre serveur doit envoyer une requête de confirmation groupée de réservations avec tous les identifiants des nouveaux joueurs, recevant dans la réponse de confirmation les informations suivantes :
affectation des réservations de joueurs acceptées à leur emplacement préféré,
affectation des réservations de joueurs expirées à leur emplacement préféré,
une liste des identifiants de joueur inconnus.
Votre serveur peut décider comment gérer chaque groupe de joueurs et s’il faut autoriser ou expulser/bannir les utilisateurs expirés ou rejetés. Chacun des emplacements de l’instance doit être mis à jour immédiatement avec le nouveau nombre de places disponibles afin de garantir que les nouvelles réservations ne dépassent pas la capacité.
Quitter le serveur
Lorsque les joueurs partent, le serveur doit mettre à jour leur emplacement assigné afin de refléter la nouvelle capacité de places disponibles.
Si la conception de votre jeu autorise une période de reconnexion, votre serveur peut attendre avant de libérer les places.
Nous recommandons d’arrêter les serveurs sans joueurs pour optimiser votre coût d’hébergement. Attendre quelques minutes avant de le faire peut réduire le nombre de redémarrages pendant de courtes périodes d’inactivité.
Lisez à propos de Persistance pour éviter des retours en arrière frustrants des serveurs persistants.
🚀 Mise à l’échelle automatisée
Server Browser est compatible avec plusieurs méthodes différentes d’autoscaling :
méthode de préchauffage - démarrer les serveurs strictement avec les politiques de mise à l’échelle de Server Browser,
méthode juste à temps - démarrer via Appariement et remplir avec Server Browser,
autoscaler personnalisé - démarrer via un backend de jeu personnalisé et remplir avec Server Browser.
Le guide suivant se concentrera sur le préchauffage avec les politiques de mise à l’échelle comme méthode principale.
Découvrez comment arrêter les déploiements dans Unreal Engine, Unity, ou avec l’API pour gérer le cycle de vie de manière fiable.
Surveiller la capacité
Les politiques de mise à l’échelle actualisent continuellement la liste de vos instances de serveur (déploiements découverts), en répétant toutes les monitoring_interval . Chaque politique peut inclure un filtre utilisant la même syntaxe de filtrage que celle utilisée par les joueurs lorsqu’ils recherchent des instances — par région, capacité ou autres critères.
Votre minimum_active_instances configuré peut être considéré soit comme un :
capacité fixe de déploiements que vous souhaitez garder en cours d’exécution à tout moment,
secours préchauffé tampon de déploiement pour masquer les délais d’initialisation.
Capacité fixe
Maintenir une quantité fixe de serveurs peut être utile particulièrement pour les jeux avec Persistance, en particulier lorsque de tels jeux permettent aux joueurs de louer Persistance.
Ce type de configuration de politique est aussi parfois utilisé pour l’assurance qualité, les tournois, les alphas fermées, les démos éditeur ou d’autres types d’événements et d’opérations à capacité limitée.
La politique de mise à l’échelle vous aide à redémarrer et recycler automatiquement à la volée les serveurs plantés ou arrêtés.
Secours préchauffé
Démarrer des serveurs avant la demande des joueurs peut être avantageux lorsque :
vous lancez des sorties majeures ou des mises à jour et attendez un afflux rapide de joueurs sur une courte période,
ou que l’initialisation du serveur nécessite plus de 30 secondes (sans compter le temps de déploiement),
ou que le jeu implémente des stratégies de maillage nécessitant des dépendances réseau complexes ou circulaires.
Avec le matchmaking, vous devrez Vue approfondie pour utiliser cette capacité avant de démarrer de nouveaux déploiements.
Déployer des serveurs
De nouveaux déploiements seront démarrés automatiquement lorsque le nombre d’instances de serveur surveillées tombe en dessous du minimum configuré d’instances actives. Tous les déploiements sont demandés immédiatement et réessayés à l’infini après écoulement de deployment_registration_period .
Vérifiez que les nouveaux déploiements effectuent la découverte automatique et créent des instances correspondant correctement à votre filtre de politique, ou votre politique peut boucler à l’infini et créer de grandes quantités de déploiements inutilisés!
Lors de la définition d’une requête de déploiement pour votre politique, nous utilisons les paramètres de déploiement standard permettant le déploiement dans des flottes privées (avec débordement vers le cloud) ou directement dans le cloud :
application et version - version du build, ressources et autres paramètres d’orchestration,
utilisateurs - un ensemble unique de coordonnées pour le placement du serveur,
ID d’hôte privés - laissez vide pour le cloud, ou spécifiez des hôtes dans la région souhaitée,
tags - étiquetez avec le nom de la politique pour retrouver plus tard les déploiements démarrés avec cette politique,
variables d’environnement - transmettez aux serveurs des paramètres personnalisés et des secrets,
webhooks - notifiez votre backend de jeu (ou matchmaker) des événements du cycle de vie du déploiement,
exiger des emplacements en cache - si vous préférez des déploiements plus rapides uniquement dans les emplacements en cache.
Exemples de politiques
Testez et modifiez n’importe laquelle de ces politiques selon vos besoins. La plupart des jeux utiliseront plusieurs politiques.
🍀 Pool d’assurance qualité (exemple minimal)
Une politique simple pour garder un serveur déployé pour les tests en permanence.
🌡️ Préchauffage de sortie par région
Chaque région démarre un déploiement avant la sortie en anticipation de la demande.
❄️ Groupe de maillage de serveurs
Une politique par groupe de serveurs, où le backend du jeu ajoute une nouvelle politique pour chaque groupe.
🔑 Serveur communautaire
Une politique par propriétaire de serveur, en transmettant un mot de passe personnalisé utilisé pour l’authentification du serveur.
🔒 MMO verrouillé par région
Chaque région ajoute des déploiements lorsque la capacité disponible tombe sous un seuil.
⚙️ Configuration
L’API Server Browser est générée à partir d’une configuration JSON spécifiée lorsque vous créez un nouveau Server Browser (ou un redémarrage rapide). Vous pouvez spécifier l’expiration du serveur et de l’emplacement, ainsi que des métadonnées personnalisées :
Pour de meilleures performances, évitez de spécifier des indices pour les métadonnées non utilisées pour le filtrage ou le tri. Les paramètres non indexés peuvent quand même être définis et lus avec les méthodes d’API de détails d’instance de serveur ou d’emplacement, voir 📗 API.
☁️ Cluster d’hébergement
Server Browser est hébergé et géré de manière pratique 24 h/24 et 7 j/7 par Edgegap.
Choisissez une option d’hébergement la mieux adaptée à votre objectif :
Niveaux de cluster privé
Passez à un cluster privé en un clic pour bénéficier d’un hébergement hautement disponible maintenu par l’équipe Edgegap avec un support en direct 24 h/24 et 7 j/7 pour les jeux publiquement publiés.
Les exigences en ressources pour votre instance dépendront des facteurs suivants :
nombre de joueurs - plus de joueurs entraînent davantage de requêtes API,
nombre de requêtes par joueur - des nouvelles tentatives plus rapides augmentent la charge du service et consomment des ressources,
nombre de serveurs - plus de serveurs entraînent davantage de données stockées et davantage de requêtes API,
logique de secours des nouvelles tentatives côté client - réessayer avec un backoff aléatoire aide à répartir les pics d’explosion du trafic,
durée moyenne d’une partie - des sessions plus courtes nécessitent une interaction plus fréquente avec le navigateur de serveurs.
📗 API
Les clients de jeu et les serveurs dédiés envoient des requêtes API tout au long de leur cycle de vie à Server Browser.
Importez la spécification API dans Client Web d’API Scalar ou Éditeur Swagger pour examiner les détails.
Pagination
Server Browser fournit une pagination par curseur pour récupérer progressivement des données filtrées dans un ordre spécifique. Cette approche nécessite l’envoi d’un curseur (point de départ) et d’une taille de page (nombre d’éléments de réponse) lors de chaque récupération de résultats supplémentaires, par opposition à la pagination traditionnelle limite-décalage.
Combinée à notre système propriétaire d’indexation de base de données développé pour les métadonnées des serveurs de jeu, la pagination par curseur offre une expérience utilisateur rapide, cohérente et flexible pour le filtrage de données très dynamiques.
Notre objectif est que les utilisateurs trouvent un serveur adapté dès la première page. Pour une meilleure expérience, nous recommandons d’afficher les résultats en cache des pages précédentes et de ne rafraîchir les résultats que lorsque l’utilisateur clique sur Rechercher.
🔖 Journal des modifications
La dernière version du navigateur de serveurs est 0.0.5 . Gardez un œil sur les mises à jour et les annonces.
0.0.5 (18 mars 2026)
Présentation de Navigateur de serveurs et Navigateur de serveurs.
Ajout de davantage de ⚙️ Configuration Des exemples pour vous inspirer.
Amélioré Navigateur de serveurs diagramme pour commencer plus rapidement.
0.0.4 (05 janv. 2026)
Entrée en BÊTA OUVERTE, introduisant le filtrage et le tri des instances de serveur et des emplacements!
0.0.3 (28 nov. 2025)
La première version du service Server Browser a été lancée en BÊTA FERMÉE.
Lister les serveurs, gérer la capacité et obtenir les détails de connexion.
Prise en charge des sessions de match avec les déploiements cloud et toujours en ligne avec les flottes privées.
Mis à jour
Ce contenu vous a-t-il été utile ?

