> For the complete documentation index, see [llms.txt](https://docs.edgegap.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.edgegap.com/fr/learn/navigateur-de-serveurs.md).
# Navigateur de serveurs
Configurez le navigateur de serveurs Edgegap pour que les joueurs puissent découvrir et rejoindre des serveurs de jeu persistants dans la région la plus proche, ou choisir depuis une interface de liste en jeu.
Commencez rapidement avec Server Browser et explorez des scénarios d’exemple pour différents genres.
Server Browser est un service géré pour [Déploiements](/fr/learn/orchestration/deployments.md#match-bound) et [Persistants](/fr/learn/orchestration/persistance.md) serveurs :
* **aider les joueurs à rechercher et rejoindre des serveurs appropriés** en fonction de la capacité, de la latence ou des paramètres du jeu ;
* **préchauffer de nouveaux serveurs** pour servir des audiences mondiales à grande échelle et éviter de frustrantes files d’attente ;
* **simplifier les opérations du serveur** y compris les mises à jour, les redémarrages, la persistance, le meshing, et plus encore.
{% hint style="success" %}
Vous cherchez à faire correspondre les joueurs selon des règles strictes, sans leur laisser le choix du serveur ? Pensez à [Matchmaking](/fr/learn/matchmaking.md).
{% endhint %}
## ✔️ Préparation
**Tester ce service est entièrement gratuit, aucune carte de crédit requise.**
Le niveau gratuit permet jusqu'à 3 heures d'exécution sur notre cluster de test partagé, après chaque redémarrage.
Ce tutoriel suppose que vous avez déjà :
* [compris le modèle de déploiement d'Edgegap](https://docs.edgegap.com/fr/learn/pages/5d7a2f9e0583a99d78071f1c4b8a7892a518534a#id-1.-just-in-time-deployment-dedicated-servers),
* publié votre application serveur sur Edgegap ([Unreal Engine](/fr/unreal-engine.md), [Unity](/fr/unity.md)),
* connecté avec succès un client de jeu à votre serveur sur Edgegap.
### Fonctions et flux
Server Browser : flux et hiérarchie
Server Browser offre deux fonctionnalités principales :
[#start-browsing](#start-browsing "mention") avec intégration client et serveur :
* Les clients réservent des places avec une seule méthode et reçoivent les détails de connexion.
* Les clients peuvent parcourir les serveurs et créneaux appropriés à l’aide de filtres personnalisés (interface en jeu).
* Les serveurs authentifient les connexions des joueurs dans les serveurs à l’aide de [Identité fédérée](#user-content-fn-1)[^1].
* Les serveurs mettent à jour la capacité des créneaux et les métadonnées pour modifier la visibilité ou déclencher une mise à l’échelle.
[#automated-scaling](#automated-scaling "mention") (fonctionnalité facultative) avec les stratégies de mise à l’échelle :
* Surveillez les instances de serveur, les créneaux et la capacité disponibles - par région ou selon des critères personnalisés.
* Déployez de nouveaux serveurs pour augmenter la capacité avec du préchauffage ou une mise à l’échelle juste-à-temps.
* Automatisez les opérations avec des stratégies isolées pour les événements à durée limitée (test QA, tournoi).
{% hint style="info" %}
Après la sortie du jeu, **votre navigateur de serveurs doit fonctionner 24 h/24, 7 j/7** pour garantir que les joueurs du monde entier puissent rejoindre les serveurs.
{% endhint %}
## ▶️ Commencer à parcourir
Apprenez le cycle de vie du serveur et du joueur (client) pour garantir une utilisation efficace du serveur.
**Commencez rapidement - ajoutez notre SDK à votre jeu**:
* Unreal Engine [Outils pour développeurs](/fr/unreal-engine/developer-tools.md#integration-kit):
* [lisez la documentation](https://egik.betide.studio/) par Betide Studios,
* [installez depuis Fab Marketplace](https://www.fab.com/listings/ff17ad88-12a1-49cf-9a41-31695ed11e16) (gratuit pour un usage personnel).
* Unity [Outils pour développeurs](/fr/unity/developer-tools.md#software-development-kit):
* [installer le package gratuitement via Unity Package Manager](https://github.com/edgegap/edgegap-unity-sdk),
* [explorez notre guide de démarrage et des exemples complets](/fr/unity/matchmaking.md).
### Authentifier
Toutes les requêtes doivent envoyer un `Authorization` en-tête HTTP avec votre secret **Jeton d'authentification :**
{% hint style="warning" %}
**Gardez vos jetons secrets et en sécurité ! Le personnel d'Edgegap ne vous demandera jamais vos jetons.**
{% endhint %}
{% hint style="info" %}
Le jeton Matchmaker et les jetons Server Browser sont distincts des jetons API d'Edgegap.
{% endhint %}
Server Browser génère automatiquement deux types de jetons :
* **Jeton serveur** - requis pour [API serveur](#server-lifecycle) méthodes, peut être [injecté comme variable de version de l’application](/fr/learn/orchestration/application-and-versions.md#injected-variables).
* Donne accès à toutes les méthodes de l’API, pratique pour les tests, le DevOps ou une mise à l’échelle personnalisée.
* **Jeton client** - requis pour [API de surveillance et API de réservation de sièges](#player-lifecycle) utilisé par les clients du jeu.
{% hint style="success" %}
Stockez le jeton client dans un coffre de secrets du backend de jeu afin de faciliter la rotation des jetons en production.
{% endhint %}
### Découvrir une instance
La découverte est le processus par lequel un serveur entièrement initialisé notifie Server Browser et devient visible [par la recherche ou des réservations auto-attribuées](#allocate-capacity).
{% hint style="warning" %}
**Nouveau** [Déploiements](/fr/learn/orchestration/deployments.md) **doit créer une nouvelle instance** lors de l’initialisation afin de suivre la capacité ajoutée.
{% endhint %}
{% hint style="info" %}
Voir [#automated-scaling](#automated-scaling "mention") pour en savoir plus sur les stratégies de mise à l’échelle et démarrer automatiquement les déploiements.
{% endhint %}
**Informations requises** pour chaque instance de serveur comprennent :
* au moins un créneau défini lors de l’initialisation de l’instance,
* détails de connexion du serveur - URL, IP, informations de port et emplacement.
**Paramètres de métadonnées personnalisés facultatifs** pour le filtrage, le tri et la navigation des joueurs ; par exemple :
* informations sur les créneaux - capacité par équipe et métadonnées spécifiques à l’équipe (par ex. nom de l’équipe),
* nom et balises - étiquettes personnalisables, uniques, lisibles par l’humain et recherchables ;
* données de compatibilité - version du serveur ou versions client prises en charge ;
* qualificatifs de latence - identifiants de ville et de région, et [Balises de ping](/fr/learn/orchestration/ping-beacons.md) détails ;
* paramètres du 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 approprié.
{% hint style="info" %}
Les paramètres de métadonnées ci-dessus ne sont que des exemples ; vous pouvez définir autant de paramètres que nécessaire.
{% endhint %}
{% hint style="success" %}
Pour sérialiser des objets imbriqués, encodez leur chemin d’accès dans la clé sous la forme `"object.child.property"`.
{% endhint %}
Les serveurs peuvent **mettre à jour les métadonnées de l’instance ou du créneau à tout moment** pour modifier leurs critères de visibilité. Lors de la mise à jour des métadonnées, toutes les clés indexées doivent être fournies avec des valeurs valides (même si elles ne sont pas modifiées).
**Les instances de serveur doivent envoyer périodiquement un heartbeat de maintien** pour vérifier leur disponibilité continue et empêcher les joueurs de rejoindre des serveurs en panne ou hors ligne. L’absence de heartbeat pendant la période d’expiration configurée supprimera automatiquement l’instance et toute réservation de sièges en attente.
{% hint style="info" %}
Voir [Persistance](/fr/learn/orchestration/persistance.md) pour gérer l’état persistant du monde et [Applications et versions](/fr/learn/orchestration/application-and-versions.md#active-caching) pour des déploiements plus rapides.
{% endhint %}
### Allouer la capacité
La capacité de l’instance et du créneau peut être allouée de deux façons, utilisées individuellement ou ensemble :
* [#auto-assigned-reservation](#auto-assigned-reservation "mention") pour choisir un serveur lancé avec une stratégie de mise à l’échelle spécifique,
* [#search-and-browse](#search-and-browse "mention") permet au joueur de définir des filtres et de parcourir les serveurs appropriés pour en choisir un manuellement.
{% hint style="success" %}
Nous recommandons de commencer avec [#auto-assigned-reservation](#auto-assigned-reservation "mention") comme option la plus simple.
{% endhint %}
#### Réservation auto-attribuée
{% hint style="info" %}
Implémentez l’auto-attribution pour **choisir automatiquement le serveur**en fonction de la région du joueur.
{% endhint %}
Les joueurs peuvent créer une réservation auto-attribuée en fournissant uniquement des identifiants de joueur et un nom de stratégie de mise à l’échelle. Server Browser trouvera automatiquement un créneau d’instance offrant une capacité joignable suffisante et réservera des places, en répondant immédiatement avec les détails de connexion de l’instance.
S’il n’existe aucun créneau d’instance approprié pour cette réservation, la réponse :
* **le code d’état indique l’état de mise à l’échelle de la stratégie** et si davantage de capacité est en cours d’ajout,
* si la montée en capacité est en cours, **en-tête `Retry-After` indique la période d’attente (en secondes) avant de réessayer**.
Une fois une réservation terminée, vous pouvez passer à [#connect-to-server](#connect-to-server "mention").
#### Rechercher et parcourir
{% hint style="info" %}
Implémentez une recherche personnalisée pour **des critères de filtrage personnalisés et/ou pour afficher aux joueurs une liste de serveurs.**
{% endhint %}
Les joueurs peuvent lister des instances de serveur avec des filtres et des tris personnalisés, et [paginer les résultats](#pagination) pour trouver un serveur qu’ils aimeraient rejoindre. Les créneaux de chaque instance peuvent être recherchés avec la même approche.
Les instances et les créneaux peuvent être filtrés et triés avec des paramètres intégrés ou [des métadonnées indexées](#configuration):
Propriété
Type de données
Instance
Créneau
request_id
chaîne
✅
❌
total_joinable_seats, total_available_seats
entier
✅
❌
name
chaîne
❌
✅
available_seats, reserved_seats
entier
❌
✅
created_at, updated_at
chaîne
✅
✅
metadata.{index} (personnalisé)
chaîne, entier, flottant, booléen
✅
✅
Les opérateurs de filtrage disponibles dépendent du type de données de la propriété filtrée :
?$filter=metadata.custom_name contains 'my game'
and metadata.server_version le '1.1.0'
and metadata.server_version ge '1.0.0'
&$order=metadata.custom_name asc
chaîne
valeurs littérales in (filtre) rank (tri)
?$filter=metadata.city in ('Chicago', 'Toronto')
&$order=rank(metadata.city, 'Chicago', 'Toronto')
{% hint style="success" %}
Filtrer et trier par `metadata.city` pour obtenir la meilleure latence après mesure avec [Balises de ping](/fr/learn/orchestration/ping-beacons.md).
{% endhint %}
{% hint style="info" %}
En savoir plus sur la pagination basée sur un curseur [#pagination](#pagination "mention") pour permettre aux utilisateurs d’obtenir plus de résultats.
{% endhint %}
#### Réserver des places
**Avant de rejoindre un serveur, les joueurs doivent réserver des places** pour garantir que l’instance offre une capacité disponible suffisante et éviter la surpopulation. Les réservations peuvent inclure un groupe de joueurs ou une seule personne.
Identité fédérée : les joueurs doivent fournir un identifiant de joueur tiers unique dans leur réservation. Une fois qu’ils [#connect-to-server](#connect-to-server "mention"), envoyez le même identifiant pour la vérification côté serveur.
Une fois la réservation effectuée avec succès, les joueurs doivent tenter de se connecter immédiatement. Les réservations en attente **expirent après 30 s (configurable) sauf confirmation** par le serveur.
**Les réservations dépassant la capacité de places rejoignables du créneau sont rejetées** ([409 Conflict](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/409)). Les places rejoignables sont toutes les places disponibles qui n’ont pas encore été réservées par d’autres joueurs.
### Se connecter au serveur
Dès que la réservation de place est effectuée, **les joueurs doivent se connecter au serveur de jeu de votre déploiement et transmettre leur identifiant joueur avec un RPC netcode**.
{% tabs %}
{% tab title="Unreal Engine" %}
Pour **se 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.
{% hint style="success" %}
En cas d’échec de connexion ou d’écran noir, consultez notre [guide de dépannage](/fr/unreal-engine.md#troubleshooting-and-faq-1).
{% endhint %}
{% endtab %}
{% tab title="Unity" %}
Pour **connectez votre éditeur Unity** ou **client de jeu** à votre déploiement cloud, saisissez :
* **Déploiement** **URL** pointant vers l’adresse IP du serveur, généralement dans `NetworkManager` composant.
* **Port externe** correspondant au [port d’écoute interne du serveur](https://docs.edgegap.com/learn/advanced-features/application-and-versions#port-mapping), généralement dans un composant Transport.
{% hint style="success" %}
En cas de délai d’attente de connexion ou d’autres problèmes, consultez notre [guide de dépannage](/fr/unity.md#troubleshooting-and-faq-4).
{% endhint %}
{% endtab %}
{% endtabs %}
Pour authentifier les nouvelles connexions, **votre serveur doit envoyer une requête de confirmation de réservation groupée** avec tous les identifiants des nouveaux joueurs, recevant en réponse :
* l’attribution des réservations de joueurs acceptées à leur créneau préféré,
* l’attribution des réservations de joueurs expirées à leur créneau préféré,
* une liste d’identifiants de joueur inconnus.
Votre **serveur décide comment gérer un groupe de joueurs expiré** et s’il faut autoriser ou expulser/bannir les utilisateurs expirés ou rejetés. Chaque **créneau d’instance doit être mis à jour immédiatement avec le nouveau nombre de places disponibles** afin de s’assurer que les futures réservations ne dépasseront pas la capacité du créneau.
{% hint style="info" %}
Votre serveur a l’autorité de modifier la capacité de n’importe quel créneau, d’ajouter, supprimer ou mettre à jour n’importe quel créneau - en supprimant toutes les réservations pour ce créneau si les réservations en attente dépassent les places disponibles.
{% endhint %}
### Quitter le serveur
Lorsque les joueurs partent, votre **serveur doit augmenter le nombre de places disponibles pour le créneau attribué**.
{% hint style="success" %}
Si votre serveur autorise une période de reconnexion, il peut attendre avant de mettre à jour les créneaux.
{% endhint %}
En savoir plus sur [Persistance](/fr/learn/orchestration/persistance.md#recovery-objectives) pour éviter de frustrants retours en arrière de serveurs persistants.
## 🚀 Mise à l’échelle automatisée
Server Browser est compatible avec plusieurs méthodes de mise à l’échelle automatique :
* **méthode de préchauffage** - démarrer des serveurs uniquement avec les stratégies de mise à l’échelle Server Browser,
* **méthode juste-à-temps** - démarrer via [Matchmaking](/fr/learn/matchmaking.md) et [remplissage avec Server Browser](#allocate-capacity),
* **autoscaler personnalisé** - démarrer via le backend de jeu personnalisé et [remplissage avec Server Browser](#allocate-capacity).
Le guide suivant se concentrera sur **le préchauffage avec les stratégies de mise à l’échelle**.
Interface utilisateur des stratégies de mise à l’échelle de Server Browser
{% hint style="success" %}
Arrêtez les déploiements dans [Unreal Engine](/fr/unreal-engine.md#stop-deployments), [Unity](/fr/unity.md#stop-deployments), ou [avec l’API](/fr/docs/api/serveurs-dedies.md#delete-v1-self-stop-request_id-access_point_id) pour contrôler la consommation du serveur de manière fiable.
{% endhint %}
### Surveiller la capacité
Server Browser actualisera la liste des instances découvertes toutes les [`monitoring_interval`](#user-content-fn-9)[^9] .
{% hint style="warning" %}
Pour **éviter la surmise à l’échelle**, définissez un intervalle de surveillance légèrement supérieur au temps moyen de démarrage du serveur.
{% endhint %}
{% hint style="info" %}
Chaque stratégie doit utiliser un filtre (avec [syntaxe de filtrage](#search-and-browse)) pour surveiller la capacité régionale.
{% endhint %}
Votre [`minimum_active_instances`](#user-content-fn-10)[^10] quantité configurée peut être considérée soit comme une :
* **capacité fixe** de déploiements que vous souhaitez maintenir en cours d’exécution en permanence,
* **veille préchauffée** tampon de déploiement pour masquer les délais d’initialisation.
#### Capacité fixe
Les stratégies à capacité fixe ne doivent pas utiliser de filtres liés aux sièges.
Ce type de configuration de stratégie est le plus souvent utilisé pour l’assurance qualité, les tournois, les alphas fermées, les démos éditeur ou d’autres événements à capacité limitée.
Alternativement, les jeux avec [Persistance](/fr/learn/orchestration/persistance.md) souhaitent généralement maintenir des serveurs de longue durée, en particulier lorsqu’ils offrent aux joueurs la possibilité de provisionner [Persistance](/fr/learn/orchestration/persistance.md#community-servers).
{% hint style="info" %}
La stratégie de mise à l’échelle vous aide à redémarrer et recycler automatiquement les serveurs en panne à la volée.
{% endhint %}
#### Veille préchauffée
Les stratégies de préchauffage doivent utiliser des filtres de places rejoignables pour surveiller l’utilisation de la capacité.
Démarrez des serveurs en veille et inactifs pour anticiper la demande des joueurs si :
* vous lancez à l’échelle mondiale et attendez un afflux rapide de joueurs sur une courte période,
* ou si l’initialisation du serveur nécessite plus de 30 secondes ([hors temps de déploiement](#user-content-fn-11)[^11]),
* ou si les serveurs utilisent des stratégies de maillage nécessitant une topologie réseau plus complexe.
### Déployer des serveurs
Les nouveaux déploiements démarrent automatiquement lorsque le nombre d’instance découvertes*s* descend en dessous du minimum d’instances actives de la stratégie. Les déploiements sont réessayés indéfiniment à chaque intervalle de surveillance une fois que deployment\_registration\_period [`deployment_registration_period`](#user-content-fn-9)[^9] s’est écoulé.
{% hint style="warning" %}
**Assurez-vous de vérifier votre** [**découverte automatique du serveur**](#discover-instance) **intégration avec votre filtre de stratégie, sinon votre stratégie peut boucler indéfiniment et créer une grande quantité de déploiements inutilisés !**
{% endhint %}
{% hint style="info" %}
Les déploiements peuvent utiliser [Flottes privées](/fr/learn/orchestration/flottes-privees.md) (avec Overflow to Cloud) ou le Cloud directement.
{% endhint %}
Les paramètres disponibles incluent ([voir la spécification complète de l’API](/fr/docs/api/serveurs-dedies.md#private-fleets)):
* [**application et version**](/fr/learn/orchestration/application-and-versions.md) - version de build, ressources et autres paramètres d’orchestration,
* **utilisateurs** - un seul ensemble de coordonnées géographiques pour le [placement du serveur](/fr/learn/orchestration/deployments.md#regional-standby),
* [**identifiants d’hôtes privés**](/fr/learn/orchestration/flottes-privees.md) - laissez vide pour le cloud, ou spécifiez des hôtes dans la région souhaitée,
* [**étiquettes**](/fr/learn/orchestration/deployments.md#dashboard-monitoring) - étiquetez avec le nom de la stratégie pour retrouver plus tard les déploiements lancés avec cette stratégie,
* [**variables d’environnement**](/fr/learn/orchestration/deployments.md#custom-variables) - transmettre des paramètres personnalisés et des secrets aux serveurs,
* [**webhooks**](/fr/learn/orchestration/deployments.md#webhooks-and-postbacks) - notifier votre backend de jeu (ou votre système de matchmaking) des événements du cycle de vie du déploiement,
* [**exigent des emplacements mis en cache**](/fr/learn/orchestration/application-and-versions.md#active-caching) - si vous préférez des déploiements plus rapides uniquement dans des emplacements mis en cache.
### Exemples de stratégies
Testez et modifiez chacune de ces stratégies selon vos besoins. La plupart des jeux utiliseront plusieurs stratégies.
{% tabs %}
{% tab title="🍀 Instance QA" %}
Une stratégie simple pour maintenir un serveur déployé en permanence pour les tests.
{% endtab %}
{% tab title="🔑 Communauté" %}
Une politique par propriétaire de serveur, en transmettant un mot de passe personnalisé défini par le propriétaire.
{% endtab %}
{% endtabs %}
## ⚙️ Configuration
L'API Server Browser est générée à partir de votre configuration JSON au démarrage de Server Browser. Vous pouvez définir des fenêtres de temps personnalisées pour l'expiration/l'enregistrement, ainsi que des métadonnées personnalisées :
{% tabs %}
{% tab title="🍀 Exemple simple" %}
{% endtab %}
{% endtabs %}
{% hint style="info" %}
Pour de meilleures performances, omettez les indices qui ne sont pas utilisés pour le filtrage ou le tri. Les paramètres non indexés peuvent néanmoins être définis et lus avec les méthodes API ou le SDK spécifique au moteur.
{% endhint %}
## ☁️ Cluster d'hébergement
Server Browser est hébergé et géré de manière pratique 24 h/24, 7 j/7 par Edgegap.
Choisissez l'option d'hébergement la mieux adaptée à votre objectif :
* **Cluster gratuit (partagé)** pour tester toutes les fonctionnalités et explorer les synergies avec votre conception,
* s'éteint automatiquement après 3 heures, nécessitant un redémarrage pour continuer les tests.
* **Cluster privé** **(dé dédié)** pour garantir un environnement stable pour vos besoins de production,
* choisissez votre région et obtenez un support 24/7 pour les jeux en direct afin de publier en toute confiance.
#### Niveaux de cluster privé
Nous proposons actuellement [3 niveaux de cluster privé](https://edgegap.com/resources/pricing#managed-infrastructure) pour répondre aux besoins de chacun :
Niveau
Niveau Hobbyiste
Niveau Studio
Niveau Entreprise
Mieux adapté pour
passionnés, développeurs indépendants
versions commerciales
lancements à fort trafic
Limite de débit (req/s)
200
750
2,000
Ressources
1 vCPU + 2 Go de RAM
6 vCPU + 12 Go de RAM
18 vCPU + 48 Go de RAM
Redondance
1 nœud virtuel
3 nœuds virtuels
3 nœuds virtuels
Prix, à l’heure
$0.0312
$0.146
$0.548
Prix, 30 jours (utilisation continue)
$22.464
$105.12
$394.56
🌟 Passez des instances gratuites à un cluster privé en un clic et obtenez un hébergement hautement disponible, maintenu par l'équipe Edgegap, avec une assistance en direct 24 h/24, 7 j/7 pour les jeux publiés au public.
Les exigences en ressources de votre instance dépendront des facteurs suivants :
* **nombre de joueurs,** plus de joueurs ⇒ plus de requêtes API et une utilisation CPU plus élevée,
* **requêtes par joueur,** des tentatives plus fréquentes ⇒ une utilisation plus élevée des ressources CPU,
* **nombre de serveurs,** plus de serveurs ⇒ une utilisation CPU et mémoire plus élevée,
* **logique de repli des tentatives côté client** - nouvelle tentative sans backoff avec jitter ⇒ [effet de troupeau](https://en.wikipedia.org/wiki/Thundering_herd_problem),
* **durée moyenne d'une partie** - des sessions plus courtes ⇒ une fréquence plus élevée des événements du cycle de vie.
{% hint style="info" %}
Nos clusters utilisent des machines cloud équipées de processeurs AMD/Intel avec une vitesse d’horloge allant jusqu’à 3,7 GHz.
{% endhint %}
## 📗 API
**Envisagez nos SDK pour** [**Unreal Engine**](/fr/unreal-engine/developer-tools.md) **ou** [**Unity**](/fr/unity/server-browser.md) **pour démarrer avec des exemples prêts à l'emploi.**
{% hint style="info" %}
Unity/Android - envisager [d'utiliser l'interpolation de chaîne brute](https://www.c-sharpcorner.com/article/convert-string-to-json-in-c-sharp/) pour empêcher la suppression de code des JSON codés en dur.
{% endhint %}
{% hint style="success" %}
**Interface Web Swagger**: le déploiement de votre service géré génère une spécification OpenAPI et une interface Web pratique, utile pour tester des cas limites ou valider la structure des charges utiles.
{% endhint %}
{% file src="/files/63beecedf9cfcbcda6307cbfa13f7756b94c87b8" %}
Importez la spécification de l'API pour [Client Web de l'API Scalar](https://client.scalar.com/workspace/default/request/default) ou [Éditeur Swagger](https://editor.swagger.io/) pour inspecter les détails.
### Limites de débit
Pour protéger votre instance contre le dépassement de la capacité de pointe et les plantages, nous limitons le nombre de requêtes client par seconde, par adresse IP publique du client.
La limite est configurée par [#configuration](#configuration "mention") paramètre `rate_limits.per_client_ip`.
{% hint style="warning" %}
Si vos clients de jeu ne réessayent pas les requêtes après avoir reçu la réponse `429 Too Many Requests` **certains joueurs peuvent être incapables de rejoindre les serveurs** lors de pics de trafic de courte durée et de périodes de trafic de pointe.
{% endhint %}
{% hint style="success" %}
**Nous recommandons de tester le comportement de l'application avec des limites de débit plus faibles pendant le développement (1 requête/s).**
{% endhint %}
#### Tests de charge
Les tests de charge dans un environnement similaire à la production entraînent un coût d’hébergement du déploiement. Consultez les ressources et les prix associés à chaque niveau sur [notre page de tarification](https://edgegap.com/resources/pricing#matchmaker).
{% hint style="warning" %}
**Utilisez** [**des clusters privés**](#private-cluster-tiers) **pour les tests de stress.** Les instances gratuites sont strictement limitées aux tests de développement uniquement.
{% endhint %}
Lors de la conception de votre test de charge, **veuillez prendre en compte des comportements de joueurs réalistes**:
| Scénario réaliste | Schéma de trafic irréaliste |
| --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| ✅ Les joueurs rejoignent la partie progressivement, augmentant les requêtes/s sur plusieurs heures. | ❌ Tous les joueurs se coordonnent et sollicitent l’API exactement à la même seconde. |
| ✅ Les joueurs attendent un temps croissant entre leurs nouvelles tentatives (p. ex. 1 s - 5 s - 10 s - 10 s). | ❌ Tous les joueurs réessaient immédiatement après avoir reçu `429 Trop de requêtes` la réponse. |
| ✅ La plupart des joueurs recevront leur affectation en peu de temps (10 à 60 s) et cesseront d’interroger le serveur. | ❌ Tous les joueurs continuent d’interroger le serveur pendant une durée déterminée même après avoir reçu leur affectation. |
| ✅ La plupart des joueurs terminent leur partie (en prenant du temps) avant de redémarrer une nouvelle session. | ❌ Tous les joueurs redémarrent immédiatement leur session dès qu’ils reçoivent l’affectation du serveur. |
| ✅ Le trafic de pointe est maintenu pendant environ 6 heures par jour, après quoi certains fuseaux horaires se déconnectent. | ❌ Le trafic de pointe est maintenu 24 heures sur 24, avec tous les joueurs jouant jour et nuit. |
#### Comportement sous charge
**Requêtes client** - si un client atteint la limite de débit req/s par IP configurée, il reçoit `429 Too Many Requests` et doit attendre avant de réessayer.
**Requêtes de déploiement** - si les politiques de mise à l'échelle déclenchent plus de déploiements que la limite req/s autorisée de votre organisation, votre navigateur de serveurs réessaiera automatiquement à chaque intervalle de surveillance, en utilisant une stratégie de round-robin pondéré entre toutes les politiques d'instances.
Les poids des politiques sont dérivés du nombre de déploiements prévus à chaque tour, en répartissant équitablement le quota de déploiement disponible entre toutes les politiques de mise à l'échelle.
### Pagination
**Server Browser fournit une pagination par curseur pour récupérer progressivement les résultats filtrés 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) à chaque fois que l'on récupère davantage de résultats, contrairement à la pagination traditionnelle par limite et décalage.
{% hint style="info" %}
La pagination par curseur, combinée à notre système d'indexation des instances par métadonnées, offre l'expérience utilisateur la plus cohérente tout en restant flexible pour filtrer des données très dynamiques.
{% endhint %}
La priorité principale 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 mis en cache pour les pages précédentes, et de rafraîchir les résultats uniquement lorsque l'utilisateur clique sur Rechercher ou demande manuellement un rafraîchissement.
## 🔖 Journal des modifications
Veuillez consulter [Notes de version](/fr/docs/release-notes.md) pour le journal des modifications à jour de ce service.
#### Versionnement sémantique
Nos outils de développement et nos services managés utilisent la version officielle [Versionnement sémantique](https://semver.org/), indiquant quelles mises à jour sont ✅ sûres (mineures, correctifs) et lesquelles peuvent contenir des changements incompatibles ⚠️ (majeurs).
**Une fois qu’une version est publiée, elle ne sera jamais modifiée/changée**.
{% hint style="warning" %}
**Pour mettre à niveau la version du service - Arrêter, Modifier, Redémarrer.** Le redémarrage rapide n’appliquera pas les changements de version.
{% endhint %}
[^1]: identifiants de joueur tiers
[^2]: valeur d'exemple
[^3]: égal à
[^4]: différent de
[^5]: inférieur à
[^6]: inférieur ou égal
[^7]: supérieur à
[^8]: supérieur ou égal
[^9]: voir Configuration
[^10]: voir les exemples de stratégies
[^11]: utilisez la mise en cache active pour réduire facilement les temps de déploiement
[^12]: * capacité fixe
* suppose que les instances fournissent le nom de la stratégie dans les métadonnées à partir d’une variable injectée
[^13]: remplacez par le nom de votre propre application
[^14]: remplacez par la version de votre propre application
[^15]: Coordonnées de Chicago
[^16]: * se déploie lorsque moins de 10 instances joignables sont trouvées
* suppose que les instances fournissent le nom de la stratégie dans les métadonnées à partir d’une variable injectée
[^17]: nous nous attendons à au moins 10 déploiements dans la région de Chicago
[^18]: * se déploie lorsque moins de 3 instances avec 5 sièges joignables ou moins sont trouvées
* suppose que les instances fournissent le nom de la stratégie dans les métadonnées à partir d’une variable injectée
[^19]: privilégiez la flotte privée si la capacité est disponible
[^20]: notifiez le backend du jeu lorsque le serveur redémarre
[^21]: * ne surveille pas la capacité
* suppose que les instances fournissent le nom de la stratégie dans les métadonnées à partir d’une variable injectée
[^22]: notifiez le backend du jeu lorsqu'il est prêt
[^23]: notifiez le backend du jeu lorsque le déploiement échoue
[^24]: les indices contiennent vos paramètres de métadonnées personnalisés utilisés pour le filtrage ou le tri
