Navigateur de serveurs

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 et Persistants serveurs :

aider les joueurs à rechercher et rejoindre des serveurs adapté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 des files d’attente frustrantes ;
simplifier les opérations des serveurs notamment les mises à jour, les redémarrages, la persistance, le maillage et bien plus encore.

Vous cherchez à faire correspondre les joueurs selon des règles strictes, sans leur permettre de choisir le serveur ? Envisagez Appariement.

✔️ 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,
publié votre application serveur sur Edgegap (Unreal Engine, Unity),
connecté avec succès un client de jeu à votre serveur sur Edgegap.

Fonctions et flux

Server Browser offre deux fonctionnalités principales :

Navigateur de serveurs avec intégration côté client et serveur :

Les clients réservent des places en une seule méthode et reçoivent les détails de connexion.
Les clients peuvent parcourir les serveurs et emplacements adaptés à l’aide de filtres personnalisés (interface en jeu).
Les serveurs authentifient les connexions des joueurs sur les serveurs à l’aide de Identité fédérée.
Les serveurs mettent à jour la capacité et les métadonnées des emplacements pour modifier la visibilité ou déclencher la montée en charge.

Navigateur de serveurs (fonctionnalité facultative) avec des politiques de montée en charge :

Surveillez les instances de serveur disponibles, les emplacements et la capacité, 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 montée en charge à la demande.
Automatisez les opérations avec des politiques isolées pour des événements à durée limitée (test QA, tournoi).

Après la sortie du jeu, votre navigateur de serveurs doit fonctionner 24 h/24 et 7 j/7 afin que les joueurs du monde entier puissent rejoindre des serveurs.

▶️ Commencer à parcourir

Découvrez le cycle de vie du serveur et du joueur (client) pour garantir une utilisation efficace des serveurs.

Authentifier

Toutes les requêtes doivent envoyer un Authorization en-tête HTTP avec votre secret Jeton d'authentification :

Autorisation : xxxxxxxx-e458-4592-b607-c2c28afd8b62

Gardez vos jetons secrets et en sécurité ! Le personnel d'Edgegap ne vous demandera jamais vos jetons.

Le jeton Matchmaker et les jetons Server Browser sont distincts des jetons API d'Edgegap.

Server Browser génère automatiquement deux types de jetons :

Jeton serveur - requis pour API serveur méthodes, peut être injecté comme variable de version de l’application.
- Donne accès à toutes les méthodes de l’API, pratique pour les tests, le DevOps ou une montée en charge personnalisée.
Jeton client - requis pour API de surveillance et API de réservation de places utilisé par les clients de jeu.

Stockez le jeton client dans un coffre-fort de secrets du backend de jeu pour faciliter la rotation des jetons en production.

Découvrir une instance

La découverte est le processus par lequel un serveur entièrement initialisé notifie Server Browser et devient visible via la recherche ou des réservations attribuées automatiquement.

Nouveau Déploiements doit créer une nouvelle instance lors de l’initialisation, afin de suivre la capacité ajoutée.

Voir Navigateur de serveurs pour en savoir plus sur les politiques de montée en charge et lancer automatiquement les déploiements.

Informations requises pour chaque instance de serveur comprend :

au moins un emplacement défini lors de l’initialisation de l’instance,
détails de connexion au 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 l’emplacement : capacité d’équipe et métadonnées spécifiques à l’équipe (par ex. nom de l’équipe),
nom et étiquettes : libellés 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 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 autant de paramètres que nécessaire.

Pour sérialiser des objets imbriqués, encodez leur chemin d’accès dans la clé sous la forme "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é. 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 signal de vie pour vérifier leur disponibilité continue et empêcher les joueurs de rejoindre des serveurs en panne ou hors ligne. L’absence de signal de vie 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.

Allouer la capacité

La capacité des instances et des emplacements peut être allouée de deux façons, utilisées individuellement ou ensemble :

Navigateur de serveurs pour choisir un serveur démarré avec une politique de montée en charge spécifique,
Navigateur de serveurs permet au joueur de définir des filtres et de parcourir les serveurs adaptés pour choisir manuellement.

Nous vous recommandons de commencer avec Navigateur de serveurs comme option la plus simple.

Réservation attribuée automatiquement

Mettez en place l’attribution automatique pour choisir automatiquement un serveur, en fonction de la région du joueur.

Les joueurs peuvent créer une réservation attribuée automatiquement en fournissant uniquement les ID des joueurs et le nom d’une politique de montée en charge. Server Browser trouvera automatiquement un emplacement d’instance offrant une capacité de jonction suffisante et réservera des places, puis répondra immédiatement avec les détails de connexion de l’instance.

S’il n’existe aucun emplacement d’instance adapté pour cette réservation, la réponse :

le code d’état indique l’état de montée en charge de la politique et si davantage de capacité est en cours d’ajout,
si la montée en charge est en cours, en-tête Retry-After indique la période d’attente (en secondes) avant une nouvelle tentative.

Une fois la réservation terminée, vous pouvez passer à Navigateur de serveurs.

Implémentez une recherche personnalisée pour des critères de filtre personnalisés et/ou pour afficher aux joueurs une liste de serveurs.

Les joueurs peuvent lister des instances de serveur avec des filtres et tris personnalisés, et paginer les résultats pour trouver un serveur qu’ils souhaitent rejoindre. Les emplacements de chaque instance peuvent être recherchés selon la même approche.

Les instances et les emplacements peuvent être filtrés et triés avec des paramètres intégrés ou des métadonnées indexées:

Propriété

Type de données

Instance

Emplacement

request_id

chaîne

✅

❌

total_joinable_seats, total_available_seats

entier

✅

❌

nom

chaîne

❌

✅

available_seats, reserved_seats

entier

❌

✅

created_at, updated_at

chaîne

✅

metadata.{index} (personnalisé)

chaîne, entier, nombre flottant, booléen

✅

Les opérateurs de filtrage disponibles dépendent du type de données de la propriété filtrée :

Paramètre

Opérateurs

Filtre d’exemple (basé sur un exemple simple)

chaîne

eq ou ne ou

lt ou le ou

gt ou ge ou contient ou

?$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 dans (filtre) rank (tri)

?$filter=metadata.city in ('Chicago', 'Toronto')
&$order=rank(metadata.city, 'Chicago', 'Toronto')

entier, nombre flottant

eq ou ne ou

lt ou le ou

gt ou ge

?$filter=metadata.xp_multiplier gt 1.0
&$order=metadata.xp_multiplier desc

booléen

eq ou ne

?$filter=metadata.allows_new_connections eq true

Filtrer et trier par metadata.city pour la meilleure latence après mesure avec Balises de ping.

Découvrez le tri basé sur un curseur Pagination pour permettre aux utilisateurs de récupérer davantage de résultats.

Réserver des places

Avant de rejoindre un serveur, les joueurs doivent réserver des places pour s’assurer que l’instance offre une capacité disponible suffisante et éviter la surcharge. Les réservations peuvent inclure un groupe de joueurs ou un joueur seul.

Identité fédérée : les joueurs doivent fournir un identifiant de joueur tiers unique dans leur réservation. Une fois qu’ils Navigateur de serveurs, envoient le même ID pour 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 joignables de l’emplacement sont rejetées (409 Conflict). Les places joignables sont 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 ID joueur via un RPC netcode.

Pour connexion 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 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 associé au port d’écoute interne du serveur, généralement dans un composant Transport.

En cas de délai de connexion dépassé ou d’autres problèmes, consultez notre guide de dépannage.

Pour authentifier les nouvelles connexions, votre serveur doit envoyer une confirmation de réservation en masse avec les ID de tous les nouveaux joueurs, et recevoir en réponse :

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 d’ID de joueurs inconnus.

Votre serveur décide comment traiter le groupe de joueurs expiré et s’il faut autoriser ou expulser/bannir les utilisateurs expirés ou rejetés. Chaque les emplacements de l’instance doivent être mis à jour immédiatement avec le nouveau nombre de places disponibles afin de garantir que les futures réservations ne dépasseront pas la capacité de l’emplacement.

Votre serveur a l’autorité de modifier la capacité de n’importe quel emplacement, d’ajouter, supprimer ou mettre à jour des emplacements - en supprimant toutes les réservations pour cet emplacement si les réservations en attente dépassent les places disponibles.

Abandonner le serveur

Lorsque les joueurs quittent, votre serveur doit augmenter le nombre de places disponibles pour l’emplacement attribué.

Si votre serveur autorise une période de reconnexion, il peut attendre avant de mettre à jour les emplacements.

Découvrez 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 de mise à l’échelle automatique :

méthode de préchauffage - démarrer les serveurs strictement avec des politiques de mise à l’échelle de Server Browser,
méthode à la demande - démarrer via Appariement et remplissage avec Server Browser,
auto-scalage personnalisé - démarrer via un backend de jeu personnalisé et remplissage avec Server Browser.

Le guide suivant se concentrera sur le préchauffage avec des politiques de montée en charge.

Arrêter les déploiements dans Unreal Engine, Unity, ou avec l’API pour maîtriser de manière fiable le coût des serveurs.

Surveiller la capacité

Server Browser actualisera la liste des instances découvertes toutes les monitoring_interval .

Pour éviter le surdimensionnement, réglez l’intervalle de surveillance légèrement au-dessus du temps moyen de démarrage du serveur.

Chaque politique doit utiliser un filtre (en utilisant la syntaxe de filtrage) pour surveiller la capacité régionale.

Votre minimum_active_instances peut être considéré 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 politiques à capacité fixe ne doivent pas utiliser de filtres liés aux places.

Ce type de configuration de politique 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.

Autrement, les jeux avec Persistance souhaitent généralement conserver des serveurs de longue durée, en particulier lorsqu’ils proposent aux joueurs de provisionner Persistance.

La politique de montée en charge vous aide à redémarrer et recycler automatiquement les serveurs en panne à la volée.

Veille préchauffée

Les politiques de préchauffage doivent utiliser des filtres de places joignables pour surveiller l’utilisation de la capacité.

Démarrez des serveurs inactifs en veille pour anticiper la demande des joueurs si :

vous lancez le jeu à l’échelle mondiale et attendez un afflux rapide de joueurs sur une courte période,
ou l’initialisation du serveur prend plus de 30 secondes (temps de déploiement non inclus),
ou les serveurs utilisent des stratégies de maillage nécessitant une topologie réseau plus complexe.

Déployer des serveurs

De nouveaux déploiements sont démarrés automatiquement lorsque le nombre d’instances découvertess passe sous le minimum d’instances actives de la politique. Les déploiements sont réessayés indéfiniment à chaque intervalle de surveillance après deployment_registration_period écoulé.

Assurez-vous de vérifier votre découverte automatique des serveurs intégration avec votre filtre de politique, sinon votre politique peut boucler indéfiniment et créer un grand nombre de déploiements inutilisés !

Les déploiements peuvent utiliser Flottes privées (avec Overflow to Cloud) ou Cloud directement.

Les paramètres disponibles comprennent (voir la spécification complète de l’API):

application et version - version de build, ressources et autres paramètres d’orchestration,
utilisateurs - un seul ensemble de coordonnées géographiques pour le placement du serveur,
ID d’hôtes privés - laisser vide pour le cloud, ou spécifier des hôtes dans la région souhaitée,
tags - étiquetez avec le nom de la politique pour retrouver plus tard les déploiements lancés avec cette politique,
variables d’environnement - transmettre des paramètres personnalisés et des secrets aux serveurs,
webhooks - notifier votre backend de jeu (ou matchmaking) des événements du cycle de vie des déploiements,
requièrent des emplacements mis en cache - si vous préférez des déploiements plus rapides uniquement dans des emplacements mis en cache.

Politiques d’exemple

Testez et modifiez l’une ou l’autre de ces politiques selon vos besoins. La plupart des jeux utiliseront plusieurs politiques.

Une politique simple pour maintenir un serveur déployé en permanence pour les tests.

{
  "name": "sb-qa-pool",
  "filter": "metadata.policy_name eq 'sb-qa-pool'",
  "deployment_request": {
    "private_host_ids": [],
    "application": "my-game-server",
    "version": "2024.01.30-16.23.00-UTC",
    "users": [
      {
        "user_type": "geo_coordinates",
        "données utilisateur": {
          "latitude": 41.881832,
          "longitude": -87.623177
        }
      }
    ],
    "tags": ["sb-qa-pool"],
    "environment_variables": [
      {
        "key": "SB_SCALING_POLICY_NAME",
        "value": "sb-qa-pool",
        "is_hidden": false
      }
    ]
  },
  "minimum_active_instances": 1
}

Lancez 10 déploiements en prévision de la demande. À copier par région.

{
  "name": "sb-v1.0.0-chicago",
  "filter": "total_joinable_seats gt 0 and metadata.policy_name eq 'sb-v1.0.0-chicago'",
  "deployment_request": {
    "private_host_ids": [],
    "application": "my-game-server",
    "version": "2024.01.30-16.23.00-UTC",
    "users": [
      {
        "user_type": "geo_coordinates",
        "données utilisateur": {
          "latitude": 41.881832,
          "longitude": -87.623177
        }
      }
    ],
    "tags": ["sb-v1.0.0-chicago"],
    "environment_variables": [
      {
        "key": "SB_SCALING_POLICY_NAME",
        "value": "sb-v1.0.0-chicago",
        "is_hidden": false
      }
    ]
  },
  "minimum_active_instances": 10
}

Ajoutez des déploiements si la capacité disponible passe sous un seuil. À copier par région.

{
  "name": "sb-mmo-chicago",
  "filter": "total_joinable_seats gt 5 and metadata.policy_name eq 'sb-mmo-chicago'",
  "deployment_request": {
    "private_host_ids": ["alpha-north-america-95fab093"],
    "application": "my-game-server",
    "version": "2024.01.30-16.23.00-UTC",
    "users": [
      {
        "user_type": "geo_coordinates",
        "données utilisateur": {
          "latitude": 41.881832,
          "longitude": -87.623177
        }
      }
    ],
    "tags": ["sb-mmo-chicago"],
    "environment_variables": [
      {
        "key": "SB_SCALING_POLICY_NAME",
        "value": "sb-mmo-chicago",
        "is_hidden": false
      }
    ],
    "webhook_on_terminated": {
      "url": "https://my-webhook.com"
    }
  },
  "minimum_active_instances": 3
}

Une politique par propriétaire de serveur, avec un mot de passe personnalisé défini par le propriétaire.

{
  "name": "sb-owner-jnjnc8mid",
  "filter": "metadata.policy_name eq 'sb-owner-jnjnc8mid'",
  "deployment_request": {
    "private_host_ids": ["alpha-north-america-95fab093"],
    "application": "my-game-server",
    "version": "2024.01.30-16.23.00-UTC",
    "users": [
      {
        "user_type": "geo_coordinates",
        "données utilisateur": {
          "latitude": 41.881832,
          "longitude": -87.623177
        }
      }
    ],
    "tags": ["community", "sb-owner-jnjnc8mid"],
    "environment_variables": [
      {
        "key": "SB_SCALING_POLICY_NAME",
        "value": "sb-owner-jnjnc8mid",
        "is_hidden": false
      },
      {
        "key": "SB_SERVER_PASSWORD",
        "value": "password1234",
        "is_hidden": false
      }
    ],
    "webhook_on_ready": {
      "url": "https://my-webhook.com"
    },
    "webhook_on_error": {
      "url": "https://my-webhook.com"
    },
    "webhook_on_terminated": {
      "url": "https://my-webhook.com"
    }
  },
  "minimum_active_instances": 1
}

⚙️ Configuration

L'API Server Browser est générée à partir de votre configuration JSON au démarrage de Server Browser. Vous pouvez spécifier des fenêtres d'expiration/d'enregistrement personnalisées et des métadonnées personnalisées :

sb-simple-example-v1-1-0.json

{
	"version": "1.1.0",
	"server_instances": {
		"expiration_period": "1m",
		"indices": {
			"policy_name": "string",
			"name": "string"
		}
	},
	"server_instance_slots": {
		"indices": {}
	},
	"seat_reservations": {
		"expiration_period": "30s"
	},
	"scaling_policies": {
		"monitoring_interval": "10s",
		"deployment_registration_period": "1m"
	},
  "rate_limits": {
    "per_client_ip": 5
  }
}

sb-social-example-v1-1-0.json

{
	"version": "1.1.0",
	"server_instances": {
		"expiration_period": "15s",
		"indices": {
			"policy_name": "string",
			"name": "string",
			"third_party_id": "string",
			"level": "string",
			"mode": "string",
			"difficulty": "string",
			"seed": "string",
			"max_players": "int",
			"app_version": "string",
			"location.city": "string"
		}
	},
	"server_instance_slots": {
		"indices": {
			"third_party_id": "string",
			"max_players": "int",
			"avg_latency": "int",
			"player_ids": "string"
		}
	},
	"seat_reservations": {
		"expiration_period": "30s"
	},
	"scaling_policies": {
		"monitoring_interval": "10s",
		"deployment_registration_period": "30s"
	},
  "rate_limits": {
    "per_client_ip": 5
  }
}

sb-cooperative-example-v1-1-0.json

{
	"version": "1.1.0",
	"server_instances": {
		"expiration_period": "15s",
		"indices": {
			"policy_name": "string",
			"name": "string",
			"third_party_id": "string",
			"level": "string",
			"mode": "string",
			"difficulty": "string",
			"avg_rank": "int",
			"max_players": "int",
			"app_version": "string",
			"tags": "string",
			"match_id": "string",
			"location.city": "string"
		}
	},
	"server_instance_slots": {
		"indices": {
			"third_party_id": "string",
			"max_players": "int",
			"player_ids": "string"
		}
	},
	"seat_reservations": {
		"expiration_period": "30s"
	},
	"scaling_policies": {
		"monitoring_interval": "10s",
		"deployment_registration_period": "30s"
	},
  "rate_limits": {
    "per_client_ip": 5
  }
}

sb-competitive-example-v1-1-0.json

{
	"version": "1.1.0",
	"server_instances": {
		"expiration_period": "15s",
		"indices": {
			"policy_name": "string",
			"name": "string",
			"third_party_id": "string",
			"avg_rank": "int",
			"max_players": "int",
			"is_ranked": "bool",
			"app_version": "string",
			"cpu_frequency": "int",
			"match_id": "string",
			"location.city": "string"
		}
	},
	"server_instance_slots": {
		"indices": {
			"third_party_id": "string",
			"max_players": "int",
			"avg_rank": "int",
			"avg_latency": "int"
		}
	},
	"seat_reservations": {
		"expiration_period": "30s"
	},
	"scaling_policies": {
		"monitoring_interval": "10s",
		"deployment_registration_period": "15s"
	},
  "rate_limits": {
    "per_client_ip": 5
  }

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 quand même être définis et lus avec les méthodes de l'API ou le SDK spécifique au moteur.

☁️ 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 plus 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é pour répondre aux besoins de chacun :

Niveau

Niveau Hobbyiste

Niveau Studio

Niveau Entreprise

Le mieux adapté pour

les passionnés, les développeurs solo

les lancements commerciaux

les lancements à fort trafic

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

Limite de débit (req/s)

200

750

2,000

Prix, à l’heure

$0.0312

$0.146

$0.548

Prix, sur 30 jours (utilisation sans interruption)

$22.464

$105.12

$394.56

🌟 Passez les 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.

Les besoins 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 - réessayer sans temporisation exponentielle avec jitter ⇒ effet de ruée,
durée moyenne d’un match - des sessions plus courtes ⇒ une fréquence plus élevée des événements du cycle de vie.

Nos clusters utilisent des machines cloud équipées de processeurs AMD/Intel avec une fréquence d'horloge de 2,4 à 3,2 GHz.

📗 API

Découvrez nos SDK pour Unreal Engine ou Unity pour démarrer avec des exemples prêts à l'emploi.

Unity/Android - envisager d'utiliser l'interpolation de chaîne brute pour empêcher la suppression de code des JSON codés en dur.

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.

sb-openapi-1-1-0.yaml

91KB

Ouvrir

Importez la spécification de l'API dans Scalar API Web Client ou Swagger Editor pour examiner les détails.

Limites de débit

Pour protéger votre instance contre le dépassement de la capacité de pic et un plantage, nous limitons le nombre de requêtes client par seconde, par adresse IP publique du client.

La limite est configurée par ⚙️ Configuration paramètre rate_limits.per_client_ip.

Si vos clients de jeu ne réessaient pas les requêtes lors de la réception d’une réponse 429 Trop de requêtes certains joueurs peuvent ne pas être en mesure de rejoindre les serveurs lors de brèves rafales et de périodes de trafic de pointe.

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).

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.

Utilisez des clusters privés pour les tests de stress. Les instances gratuites sont strictement limitées aux tests de développement uniquement.

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 requêtes/s par IP configurée, il reçoit 429 Trop de requêtes et doit patienter 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 de req/s autorisée de votre organisation, votre Server Browser réessaiera automatiquement à chaque intervalle de surveillance, en utilisant une stratégie de round-robin pondéré entre toutes les politiques d'instance.

Les poids des politiques sont dérivés du nombre de déploiements prévus à chaque tour, 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 d'envoyer un curseur (point de départ) et une taille de page (nombre d'éléments de réponse) à chaque récupération de résultats supplémentaires, contrairement à la pagination traditionnelle par limite/décalage.

La pagination par curseur, combinée à notre système d'indexation des instances de métadonnées, offre l'expérience utilisateur la plus cohérente tout en restant flexible pour filtrer des données très dynamiques.

La priorité principale est que les utilisateurs trouvent un serveur approprié sur la première page.

Pour une meilleure expérience, nous recommandons d'afficher les résultats mis en cache des pages précédentes et de n'actualiser les résultats que lorsque l'utilisateur clique sur Rechercher ou demande manuellement un rafraîchissement.

🔖 Journal des modifications

Versionnage sémantique

Nos outils de développement et nos services managés utilisent les officielles Versionnage sémantique, 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.

La dernière version de Server Browser est 1.1.0 . Restez à l'affût de mises à jour et annonces.

PrécédentRegard approfondi

SuivantFonctionnalités avancées

Mis à jour il y a 24 jours

Ce contenu vous a-t-il été utile ?

✔️ Préparation

Fonctions et flux

▶️ Commencer à parcourir

Authentifier

Découvrir une instance

Allouer la capacité

Réservation attribuée automatiquement

Recherche et navigation

Réserver des places

Se connecter au serveur

Abandonner le serveur

🚀 Mise à l’échelle automatisée

Surveiller la capacité

Capacité fixe

Veille préchauffée

Déployer des serveurs

Politiques d’exemple

⚙️ Configuration

☁️ Cluster d’hébergement

Niveaux de cluster privé

📗 API

Limites de débit

Tests de charge

Comportement sous charge

Pagination

🔖 Journal des modifications

Versionnage sémantique