Ctrlk
edgegap.comDashboard
discordlinkedin
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Déploiements

En savoir plus sur les déploiements et leur cycle de vie - concepts et bonnes pratiques pour une compréhension approfondie.

🗺️ Orchestration

Lancez de nouveaux serveurs en quelques secondes pour répondre aux besoins de capacité grâce à notre approche de calcul en périphérie cloud native. Nous traitons les serveurs comme du bétail plutôt que des animaux de compagnie - en remplaçant entièrement les instances défaillantes au lieu de les soigner manuellement une par une.

Votre choix d’orchestration aura un impact sur vos coûts DevOps, le coût des serveurs et la scalabilité.

Contactez-nous sur Discord pour en savoir plus sur les options d’orchestration hybride et sur l’optimisation de vos coûts d’hébergement.

Pour bien comprendre tous les avantages et inconvénients, comparons différentes méthodes d’orchestration. Certains jeux utiliseront plusieurs méthodes d’orchestration selon la conception de la boucle de jeu.

Lié au match

Les serveurs à courte durée de vie (limitée dans le temps) se réduisent à la fin du match, offrant le meilleur rapport coût-performance.

Les sessions sont généralement automatisées via un Appariement service, qui déploie des serveurs juste à temps selon des règles strictes, et permet éventuellement de remplir les serveurs en cours pour améliorer les taux de remplissage des matchs.

👍 Avantages

  • Meilleure efficacité des coûts - mise à l’échelle en temps réel pour répondre à la demande des joueurs minute par minute.

  • Coût DevOps le plus faible grâce à un hébergement sans région ; Edgegap automatise 99 % des tâches.

  • Ping le plus faible grâce à plus de 615 sites dans l’infrastructure cloud publique d’Edgegap.

  • Mise à l’échelle la plus rapide (capacité de pic) en cas de hausse inattendue du trafic.

  • Plus haut niveau de sécurité et de prévention de la triche des joueurs (autorité serveur).

  • Impact minimal d’une panne serveur inattendue sur les joueurs, n’affectant qu’un seul match.

👎 Inconvénients

  • L’adoption d’un nouveau modèle mental d’orchestration nécessite initialement un certain effort d’adaptation.

  • Les serveurs exécutés pendant plus de 24 heures seront automatiquement arrêtés.

🧩 Le mieux adapté pour

  • Jeux sensibles à la latence - lorsque l’optimisation du netcode ne peut pas compenser un ping élevé :

    • FPS, jeux de combat, VR et XR (réalité virtuelle et étendue), …

  • Jeux avec une limite supérieure de durée de match par conception,

    • Battle Royale, PvPvE, jeux coopératifs, MOBA, jeux de sport, ARPG et dungeon crawlers, …

Edgegap ajuste automatiquement à la hausse/à la baisse tous les plus de 615 emplacements de serveurs en fonction de l’activité des joueurs dans chaque région. Préparez-vous au succès - passez sans friction à 14 millions d’utilisateurs simultanés en 60 minutes passer à 14 millions d’utilisateurs simultanés en 60 minutes.

Veille régionale

Jeu MMO à monde persistant et social la durée de vie du serveur dépasse souvent les sessions individuelles des joueurs.

Les sessions sont généralement attribuées via un Navigateur de serveurs en fonction de la préférence du joueur (automatisée par région ou recherche personnalisée), avec une pré-mise à l’échelle du déploiement horizontal basée sur la capacité régionale.

👍 Avantages

  • Approche familière et facile à comprendre, à l’ancienne, pour les vétérans aguerris.

  • Plus haut niveau de sécurité et de prévention de la triche des joueurs (autorité serveur).

  • Coût facilement prévisible basé sur un engagement mensuel.

👎 Inconvénients

  • Coût d’hébergement plus élevé - chaque région nécessite un ou plusieurs serveurs de veille inactifs (capacité de pic).

  • Coût DevOps plus élevé - mise à l’échelle, opérations et maintenance dupliquées par région.

  • Les régions avec une base de joueurs plus réduite subissent un ping élevé en raison de la connexion à des serveurs éloignés.

🧩 Le mieux adapté pour

  • Mondes persistants avec contenu généré par les utilisateurs stocké sur le serveur même lorsque les joueurs sont hors ligne.

    • MMO, sandbox avec construction de bases ou placement d’objets, Extraction Shooters, ...

  • jeux tolérants à la latence - lorsque la physique en temps réel avec autorité serveur n’est pas requise:

    • jeux mobiles, jeux coopératifs, TCG/CCG, stratégies au tour par tour, …

  • Multijoueur asynchrone, où les pannes serveur ont un impact minimal sur l’expérience du joueur :

    • course contre des fantômes, piller la base ennemie, jeux de construction/agriculture à minuterie, …

  • applications avec un processus d’initialisation lourd - lorsque la préparation des serveurs prend plusieurs minutes.

Pair à pair

Déplacez les efforts de développement des serveurs dédiés vers netcode relais pour les jeux non compétitifs.

Sujets connexes : serveurs d’écoute, autorité de l’hôte-joueur, traversée NAT.

👍 Avantages

  • Coût d’hébergement le plus faible, ne nécessitant que des serveurs relais pour résoudre la traversée NAT.

  • Coût DevOps le plus faible - maintenance requise uniquement pour les builds client et les canaux de distribution.

  • Impact minimal d’une panne serveur inattendue sur les joueurs, n’affectant qu’un seul match.

  • Facile à mettre en œuvre et rapide à prototyper, sans aucun développement backend requis.

👎 Inconvénients

  • Effort de développement du netcode pair à pair accru, nécessitant des compétences en programmation concurrente.

  • Les pings les plus mauvais et la plus grande sensibilité aux conditions réseau défavorables (par ex. Internet mobile).

  • Sécurité la plus faible, vulnérable aux attaques de l’homme du milieu et au détournement de session.

  • Risque de perte de sessions lorsque l’hôte quitte, sauf si vous implémentez une migration d’hôte personnalisée.

🧩 Le mieux adapté pour

  • Jeux coopératifs et casual - lorsque la triche ne gâche pas le plaisir ni ne casse le jeu,

    • Jeux pour enfants, jeux d’exploration, aventures, …

Voir nos Relais distribués pour un service permettant le pair à pair avec une latence et une sécurité de premier ordre.

📍 Placement des serveurs

Quelle que soit la méthode d’orchestration que vous choisissez, sélectionner le bon emplacement de serveur pour un groupe de joueurs est crucial pour garantir le meilleur ping possible et une expérience joueur optimale. Découvrez différentes stratégies de placement des serveurs et leur impact sur vos joueurs.

Votre stratégie de placement des serveurs aura un impact sur l’expérience de vos joueurs, leur rétention et les avis sur votre jeu.

Edgegap déploie dans le meilleur emplacement possible avec la capacité disponible, pour des matchs rapides et à faible latence.

Voir Déploiements vers analyser le placement des serveurs en temps réel, à grande échelle.

Score serveur

La stratégie Server Score utilise la méthode brevetée d’Edgegap, qui optimise le placement des serveurs pour chaque match individuellement. Effectue une télémétrie non intrusive pour approximer la proximité réseau de chaque joueur à nos emplacements de serveurs et choisir le serveur qui offre le meilleur :

  • temps de réponse - offre en moyenne le ping le plus faible pour tous les joueurs,

  • équité - offre un ping équilibré et équitable pour tous les joueurs.

Notre Matchmaker utilise par défaut la stratégie Server Score, afin de garantir la meilleure expérience possible. Pour utiliser cette stratégie avec les API de déploiement, saisissez les IP publiques des joueurs ou les coordonnées géographiques dans votre requête de déploiement.

Placement non réactif - le serveur est éloigné, ping élevé pour tous les joueurs :

Placement injuste - ping inégal, un joueur est désavantagé en raison d’une latence plus élevée :

Exemple de bon placement - ping réactif et équitable pour tous les joueurs :

Cette stratégie est particulièrement efficace pour héberger un groupe de joueurs éloignés les uns des autres (Amérique du Nord vs Amérique du Sud, ou côte ouest vs côte est), cas fréquent avec une base de joueurs plus réduite.

Géolocalisation

Sinon, indiquez les coordonnées latitude et longitude de l’emplacement de serveur souhaité :

⭐ Recommandé : Trouvez la balise de ping la plus rapide et envoyez ses coordonnées, ou son IP dans le champ utilisateur.

⚙️ Personnalisé: Définissez des régions (avec leurs coordonnées) dans le backend de votre jeu, récupérez-les via une API personnalisée.

👉 Le plus simple pour les tests : Définissez des régions (avec leurs coordonnées) en dur dans les builds de développement du client du jeu.

Cette stratégie n'est pas recommandée pour Déploiements l'orchestration, sauf pour les applications soumises à des exigences réglementaires strictes en matière de transferts de données interrégionaux, ou lorsque l'adresse IP du joueur n'est pas disponible.

Alternativement, laissez les joueurs choisir un serveur persistant (toujours en ligne) d'une liste avec Navigateur de serveurs.

Verrouillage régional

Certains studios préfèrent verrouiller des emplacements stables et prévisibles (p. ex. des MMO avec Persistance). Envisagez Navigateur de serveurs avec des politiques de mise à l’échelle régionales et des réservations attribuées automatiquement.

Cette stratégie n'est pas recommandée pour Déploiements l'orchestration, sauf pour les applications soumises à des exigences réglementaires strictes en matière de transferts de données interrégionaux, ou lorsque l'adresse IP du joueur n'est pas disponible.

🟢 Qualité de connexion

Certains jeux (et joueurs) sont plus sensibles à la latence ou au lag que d’autres. Bien que les signalements des joueurs soient un excellent indicateur d’incidents ou de régressions à grande échelle, les joueurs peuvent manquer d’une compréhension approfondie des concepts de réseau et attribuent rapidement la faute aux studios, au netcode ou aux serveurs.

La cause profonde de certains problèmes peut être cachée aux joueurs, de sorte que la coopération entre le studio et le fournisseur d’hébergement peut être cruciale. La priorité d’Edgegap est toujours de fournir le meilleur service possible.

Si vous recevez de nombreux signalements de joueurs, si vous subissez des pannes généralisées ou des problèmes répétés, veuillez nous contacter immédiatement via un ticket de support sur notre plateforme.

Si vous avez besoin d’aide, veuillez nous contacter sur Discord. Pour l’assistance aux jeux en direct, consultez notre système de tickets.

Faible latence

La latence du joueur est une combinaison des latences liées au transfert des données entre :

  • Appareils physiques - le signal physique voyageant à travers la topologie du réseau Internet.

  • De serveur à serveur - résultant des mesures de protocole, de transport et de sécurité.

  • De processus à processus - résultant du déballage et du traitement des données côté client/serveur.

Edgegap réduit la latence physique en plaçant les serveurs plus près de vos joueurs pour des réponses plus rapides et un nombre de sauts réseau réduit. Avec des emplacements répartis sur 17 fournisseurs cloud et bare metal, vous obtenez le meilleur ping du marché pour les joueurs partout dans le monde.

La couverture mondiale des serveurs et d’Internet (pas seulement chez Edgegap) est limitée par des facteurs tels que :

  • Disponibilité de l’infrastructure - la qualité de la connexion Internet dans une région donnée peut ne pas être suffisante.

  • Facteurs naturels - les serveurs incluent des composants sensibles, nécessitant de la stabilité (pas de tremblements de terre).

Haute disponibilité

La disponibilité des serveurs dans différentes régions du monde varie au fil du temps, changeant de nombreuses fois au cours de la journée. Edgegap ajuste automatiquement à la hausse/à la baisse les emplacements à la demande, en tenant compte de :

  • Trafic en pic - les déploiements effectués sur une période de 15 minutes informent les tendances de mise à l’échelle.

  • Besoins en ressources - la demande totale en vCPU dans chaque emplacement détermine le rythme de mise à l’échelle.

  • Alternatives de fournisseurs - certains emplacements éloignés disposent de moins d’options de fournisseurs.

  • Capacité des fournisseurs - certains emplacements n’offrent peut-être que des machines 4 vCPU ou 8 vCPU.

  • Qualité de service - certains fournisseurs offrent une meilleure qualité réseau entre les FAI d’une même zone.

  • Planning du studio - demandes spéciales pour les tests et l’assurance qualité, les bêtas fermées ou les tournois.

Toutes les requêtes de déploiement des applications sont combinées pour évaluer la demande dans chaque emplacement. Toutes les organisations ont par défaut la même priorité d’allocation. Les studios ont la possibilité d’ajouter des éléments personnalisés Flottes privées.

Veuillez nous contacter pour planifier une mise en production, ou si vous avez des demandes concernant la disponibilité des emplacements.

Résolution des problèmes des joueurs

Les problèmes des joueurs peuvent parfois être causés par des bugs de serveur ou d’hébergement, mais ils sont souvent sans rapport - pensez aussi aux problèmes de connexion câble/Wi‑Fi, au fournisseur d’accès Internet, aux services backend ou aux bugs dans les bibliothèques bas niveau client/serveur.

Lors du dépannage des signalements ou incidents des joueurs, tenez compte des facteurs suivants :

  • Qualité du matchmaking - optimisez autant que possible pour des matchs dans la même région :

  • Problèmes régionaux de réseau et de FAI :

    • les fournisseurs d’accès à Internet (FAI) localisés peuvent être en train de résoudre un incident momentanément,

    • certaines régions (par ex. la Chine, la Russie) peuvent être restreintes en raison de sanctions localisées.

  • Niveau de cache - sans cache, vos sessions peuvent expirer en raison de déploiements plus lents :

  • Temps maximum de déploiement - les déploiements peuvent échouer en raison d’un processus d’initialisation lent et lourd :

  • Problèmes d’image serveur ou d’intégration dans les premières itérations de pipelines de build personnalisés.

Afficher les ID de déploiement dans l’interface d’historique des matchs du client pour suivre les signalements des joueurs lors du dépannage.

Informer les utilisateurs des bugs généralisés, des problèmes temporaires et des pannes afin d’atténuer le sentiment négatif.

🔄 Cycle de vie du déploiement

Les déploiements Edgegap passent par plusieurs étapes de cycle de vie, indiquées par l’état du déploiement.

1. Démarrer un déploiement

Un déploiement à des fins de test peut être lancé avec :

  • Unreal Engine - l’extension Docker ou le plugin EGIK pour les projets Unreal Engine.

  • Unity - le plugin de démarrage rapide d’hébergement pour les projets Unity.

  • Godot - le plugin de démarrage rapide d’hébergement pour les projets Godot.

  • Interface web du tableau de bord - interface web simple pour des tests rapides de serveur et l’itération.

Lancer vos déploiements manuellement, en collant l’URL et les ports, ne suffira pas pour un jeu en direct.

Automatisez les flux de jeu populaires pour gérer les sessions et la mise à l’échelle à la demande avec l’une ou l’autre des options suivantes :

Appariement:

  • Manches plus courtes

  • Parties à la demande

  • Classement par niveau et/ou Règles personnalisées

Navigateur de serveurs:

  • Persistant ou en manches

  • Hubs régionaux sociaux

  • Affectation automatique et/ou Recherche personnalisée

Backend personnalisé :

Enregistrer request_id (ID de déploiement) et taguer les déploiements pour identifier et dépanner les problèmes plus tard.

2. Déploiement

Une fois un déploiement lancé, notre système effectuera un certain nombre d’étapes à la suite, très rapidement :

  • Télémétrie - nous mesurons la réactivité du réseau depuis les centres de données disponibles vers chaque joueur,

  • Déploiement - nous réservons de la capacité et préparons le démarrage de votre conteneur serveur,

  • Démarrage du conteneur - nous démarrons le conteneur, installons les dépendances et initialisons,

  • Post-traitement - nous ajoutons le stockage des journaux, la surveillance et finalisons le déploiement.

Activer Activer la mise en cache dans la version de votre application pour déployer des serveurs en quelques secondes.

Trop de requêtes 429 - pour garantir la stabilité et éviter les factures surprises, nous limitons le débit de votre organisation à 40 req/s. Contactez-nous pour planifier les lancements, estimer le trafic de lancement et préparer le succès.

3. Déploiement prêt

Une fois un déploiement prêt, votre moteur a encore du travail à faire. Les moteurs initialisent les sous-systèmes et les frameworks, puis chargent les ressources, y compris les cartes, en mémoire. Cela se produit après que votre déploiement devient prêt et prend généralement jusqu’à 1 minute selon votre degré d’optimisation.

Réessayez la connexion du joueur plusieurs fois, jusqu’à ce qu’une période de délai d’attente prédéfinie s’écoule, avant de revenir en arrière et de démarrer une nouvelle session. Les serveurs n’acceptent généralement pas de nouvelles connexions de joueurs tant qu’ils ne sont pas complètement initialisés.

La gestion des plantages du serveur dépend de votre politique de redémarrage du processus. L'état du serveur peut être perdu.

Selon le statut de la version, Applications et versions vous pouvez recevoir :

🟢 Succès de cache

La mise en cache est activée. Le déploiement a été plus rapide grâce à la réutilisation de l’image préchargée sur cette machine.

🟡 Démarrage à chaud

La mise en cache est désactivée. Le déploiement a été plus rapide grâce à la réutilisation de l’image téléchargée pour un déploiement précédent sur la même machine. Activez la mise en cache pour garantir des déploiements constamment rapides dans le monde entier.

🔴 Échec de cache

La mise en cache est activée. Le déploiement a été plus lent en raison d’un pic de trafic soudain avant la fin de la propagation du cache. L’activation de « require cached locations » dans votre requête de déploiement empêchera cela, mais peut entraîner davantage de déploiements non traitables lors de pics de trafic inattendus.

🔴 Démarrage à froid

La mise en cache est désactivée. Le déploiement a été plus lent, l’image a été téléchargée au moment du déploiement. Activez la mise en cache pour un déploiement plus rapide.

4. Erreur de déploiement

Votre déploiement peut passer à l’état Non traitable à tout moment, pour des raisons inattendues. Cela est plus susceptible de se produire lors des tests de votre intégration ou lors des tests de nouvelles versions serveur.

Les déploiements en erreur ne vous sont pas facturés et sont automatiquement arrêtés après 24 heures.

Étapes de dépannage :

Si vous avez besoin d’aide, veuillez nous contacter sur Discord. Pour l’assistance aux jeux en direct, consultez notre système de tickets.

Lorsque vous demandez de l’aide, incluez votre ID de déploiement et tout détail utile afin que nous puissions enquêter rapidement !

5. Déploiement arrêté

Les déploiements cloud seront arrêtés après 24 heures d’exécution conformément à notre politique de nettoyage des serveurs pour la maintenance de l’infrastructure, et afin d’éviter d’engendrer des coûts inattendus lorsqu’un déploiement n’a pas été correctement arrêté à cause d’un bug inattendu.

Pour des serveurs de longue durée de plus de 24 heures, envisagez d’utiliser Flottes privées avec Persistance.

Optimisez vos coûts et arrêtez plus tôt les déploiements inactifs grâce aux méthodes suivantes :

  • Version de l’application Politique de redémarrage - empêcher le redémarrage automatique à l’arrêt ou en cas de plantage.

  • Durée maximale du jeu - le temps alloué dans votre Applications et versions est expiré.

  • Arrêt automatique via DELETE_URL - le déploiement s’est arrêté de lui-même après le départ des joueurs et la fin du match.

    • Voir Unreal Engine et Unity guides pour les utilitaires du SDK et une intégration facile, ou utilisez l’API.

  • Arrêt depuis un backend personnalisé - votre orchestration de session personnalisée peut utiliser API des déploiements.

  • Flottes privées L’hôte exécutant votre déploiement a été supprimé via une action planifiée.

Une fois qu’un déploiement est arrêté, nous déclenchons une terminaison gracieuse en envoyant SIGTERM un signal à votre processus principal, ce qui permet un court délai d’arrêt. Une fois ce délai expiré, un SIGKILL signal est envoyé pour arrêter le déploiement.

👀 Observabilité

Permettre aux serveurs de jeu d’interopérer avec des tiers et d’obtenir des informations opérationnelles.

Vous vous inquiétez des coûts cloud inattendus ? Configurer des alertes cloud pour être averti lorsque des seuils de facturation personnalisés sont atteints, ou contactez-nous au sujet de mesures de sécurité automatisées.

Découvrabilité

Une fois prêt, le déploiement reçoit une URL (fqdn) et un port externe pour chaque port interne.

Utilisez des tags de déploiement (jusqu’à 40 caractères) pour marquer facilement vos déploiements pour les retrouver plus tard.

Le trafic sortant (vers les clients ou le backend) depuis vos serveurs de jeu n’est jamais bloqué ou filtré.

WebSockets (WS) et WebSockets sécurisés (WSS)

Pour utiliser un netcode basé sur les WebSockets avec Edgegap, vous avez deux options :

  • certificat géré, configuré en 1 minute sans écrire de code :

    • configurez votre Applications et versions vers utilisez WebSocket (WS) et activez la mise à niveau TLS,

    • utilisez l’URL Edgegap pour connecter les clients (p. ex. https://5fa53fa00a57.pr.edgegap.net/)

  • certificat autogéré, si vous souhaitez utiliser votre propre domaine personnalisé :

    • configurez votre Applications et versions vers utilisez Secure WebSocket (WSS),

    • configurez votre propre flux de certificat TLS avec un enregistrement DNS personnalisé (par ex. sur Cloudflare).

Les exceptions serveur non capturées entraîneront le redémarrage du conteneur du déploiement et invalideront la sécurité TLS. Dans ce cas, arrêtez votre serveur et réattribuez les joueurs à un nouveau déploiement. L'état du serveur peut être perdu.

Variables injectées

Les serveurs de jeu ont souvent besoin d'informations supplémentaires, telles que l'IP du serveur, les valeurs de ports internes ou autres. Injecter des variables d'environnement en lecture seule est un moyen fiable et indépendant du cloud pour transmettre des paramètres.

Obtenez les valeurs des variables avec Unity SDK, Unreal EGIK, ou avec les méthodes de variables d'env. de votre runtime.

Voir Variables de version d'application et Variables du matchmaking en plus des variables de déploiement ci-dessous.

Variables personnalisées

Définissez jusqu'à 20 variables personnalisées pour chaque déploiement, chacune contenant jusqu'à 4 Ko de données texte.

Évitez d'utiliser les noms réservés ci-dessous, sinon vos variables personnalisées seront écrasées !

Accédez aux informations importantes en lisant les variables injectées par Edgegap à vos serveurs :

Identifiants

  • ARBITRIUM_REQUEST_ID - p. ex. f68e011bfb01 .

    • Identifiant unique du déploiement, également appelé identifiant de requête. Utilisé pour obtenir plus d'informations.

    • Les URL de déploiement ont toujours le format {ARBITRIUM_REQUEST_ID}.pr.edgegap.net.

  • ARBITRIUM_PUBLIC_IP - p. ex. 162.254.141.66 .

    • Adresse IP publique de cet hôte, peut être utilisée pour se connecter à la place de l'URL.

  • ARBITRIUM_HOST_ID - p. ex. alpha-north-america-70364ef8 .

    • Identifiant unique de la machine hébergeant votre déploiement, partagé avec d'autres déploiements.

  • ARBITRIUM_DEPLOYMENT_TAGS - p. ex. tag1,tag2 .

  • ARBITRIUM_PRIVATE_FLEET_ID - p. ex. PUBLIC_CLOUD , ou l'identifiant du parc si hébergé sur Flottes privées.

Spécifications des ressources

  • ARBITRIUM_HOST_IN_PRIVATE_FLEET - p. ex. false , indiquant si hébergé sur Flottes privées.

  • ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY - p. ex. 2300 , fréquence du processeur en MHz.

  • ARBITRIUM_DEPLOYMENT_VCPU_UNITS - p. ex. 256, unités vCPU allouées (1024 = 1 vCPU).

  • ARBITRIUM_DEPLOYMENT_MEMORY_MB - p. ex. 512, RAM allouée en MB (1024 = 1 GB).

Gestion du cycle de vie

  • ARBITRIUM_DELETE_URL - p. ex. https://api.edgegap.com/v1/self/stop/9f511e17/660.

  • ARBITRIUM_DELETE_TOKEN - p. ex. 7df4cd933df87084b34ae80d8abde293.

  • ARBITRIUM_CONTEXT_URL - p. ex. https://api.edgegap.com/v1/context/9170f5211e17/17.

    • Appelable uniquement depuis le déploiement, renvoie plus de détails sur le déploiement.

    • Nécessite un jeton unique ARBITRIUM_CONTEXT_TOKEN dans Authorization en-tête.

  • ARBITRIUM_CONTEXT_TOKEN - p. ex. dfaf50b9333b9ee07b22ed247e4a17e6.

Découvrabilité

  • ARBITRIUM_PORT_GAMEPORT_INTERNAL - p. ex. 7777 , port interne pour l'écoute du serveur.

  • ARBITRIUM_PORT_GAMEPORT_EXTERNAL - p. ex. 31504 , port externe pour les connexions client.

    • Les valeurs du port externe sont randomisées pour chaque déploiement à des fins de sécurité.

  • ARBITRIUM_PORT_GAMEPORT_PROTOCOL - p. ex. UDP , protocole de votre transport netcode.

Les exemples supposent que vous avez nommé votre port gameport (par défaut). Chaque port ajoute un ensemble supplémentaire de variables assainies Applications et versions variables : @Super Port ! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .

  • ARBITRIUM_BEACON_ENABLED - p. ex. true, si le déploiement est hébergé sur Flottes privées avec Balises de ping.

  • ARBITRIUM_HOST_BEACON_PUBLIC_IP - p. ex. 139.177.198.69 , IP publique du point de référence le plus proche.

  • ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL - p. ex. 30199, pour la mesure du ping via UDP.

  • ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL - p. ex. 30456, pour la mesure du ping via TCP.

Informations structurées (JSON sous forme de chaîne)

Les variables d'environnement sont stockées sous forme de JSON sérialisés en chaîne, analysez-les à l'aide d'un SDK ou d'une méthode personnalisée.

ARBITRIUM_DEPLOYMENT_LOCATION
ARBITRIUM_PORTS_MAPPING

Surveillance du tableau de bord

Notre Tableau de bord fournit des outils pour surveiller la montée en charge de votre serveur et faciliter les opérations.

Analyses

Trouvez les tableaux de bord d'analyses dans le menu latéral dans la catégorie Hébergement et orchestration de serveurs.

🌟 Passez à l'offre Pay as You Go pour débloquer des métriques et des analyses détaillées des performances du serveur :

  • Aperçus généraux : surveillez les déploiements avec le nombre de serveurs en direct par version + aperçu de l'utilisation des ressources,

  • Aperçus CPU: dépannez les serveurs ralentis en raison d'opérations gourmandes en processeur,

  • Aperçus mémoire: réduisez les redémarrages du serveur dus au dépassement de la mémoire allouée,

  • Aperçus réseau : détectez les schémas réseau inefficaces et optimisez le netcode.

Carte de déploiement

Trouvez la carte de déploiement dans la page des détails de votre déploiement sur le tableau de bord.

Prévisualisez l'emplacement du déploiement, les emplacements disponibles et les emplacements estimés des joueurs sur la carte :

Points d'équilibre du déploiement

Trouvez la carte thermique des points d'équilibre du déploiement dans la page des détails de votre application sur le tableau de bord.

Prévisualisez la carte thermique des points d'équilibre du déploiement et filtrez par Applications et versions. Les points d'équilibre sont des emplacements approximatifs présentant une proximité réseau égale pour chaque joueur dans un déploiement donné :

Les points chauds des points d'équilibre dans des endroits inhabituels (p. ex. le Groenland) indiquent un matchmaking de joueurs éloignés les uns des autres. En savoir plus sur Déploiements et Balises de ping pour optimiser votre matchmaking.

Journaux de déploiement

Trouvez les journaux de déploiement dans la page des détails de votre déploiement sur le tableau de bord.

Les journaux de déploiement affichent des informations sur Déploiements:

Journaux du conteneur

Trouvez les journaux du conteneur dans la page des détails de votre déploiement sur le tableau de bord.

Inspectez les journaux de votre serveur de jeu en cas de problème ou lors du débogage :

Une fois le déploiement arrêté, les journaux du conteneur sont supprimés. Configurez le stockage de journaux S3 tiers pour enregistrer les journaux.

Métriques du conteneur

Trouvez les métriques du conteneur dans la page des détails de votre déploiement sur le tableau de bord.

Examinez les métriques du conteneur (processeur, mémoire, réseau) pour :

  • identifier les problèmes de connexion courants lorsque Déploiements,

  • détecter des schémas d'implémentation inefficaces provoquant des pics d'utilisation des ressources,

  • repérer une utilisation inefficace des ressources dans des scénarios particuliers,

  • vérifier les changements dans l'utilisation des ressources de votre serveur pendant l'optimisation,

  • mesurer la consommation de ressources et la durée d'initialisation de votre serveur.

Les métriques d'historique affichent des moyennes sur des périodes d'une minute, disponibles dans l'offre Free.

🌟 Passez à l'offre Pay as You Go pour débloquer des métriques précises avec des intervalles d'une seconde.

Contactez-nous avant votre publication afin de demander une assistance à l'hébergement en direct pour les lancements à grande échelle.

Contexte et statut

Des informations supplémentaires sur le déploiement peuvent être récupérées au format JSON :

L'API Context (depuis le déploiement) nécessite un jeton d'API Context, tandis que l'API Status utilise votre jeton Edgegap.

Trop de requêtes 429 - les API Context et Status sont limitées à 20 req/s par organisation. Ces API sont destinées à être utilisées lors d'opérations spéciales, et non pour l'orchestration automatisée de sessions.

Utilisez Webhooks pour une orchestration personnalisée des sessions afin d'éviter la limitation de débit et d'assurer l'évolutivité.

Filtrer les déploiements

Pour rechercher rapidement parmi tous les déploiements, vous pouvez utiliser notre tableau de bord:

Alternativement, laissez les joueurs choisir un serveur persistant (toujours en ligne) d'une liste avec Navigateur de serveurs.

Lister les déploiements avec l'API et appliquer des filtres avec les intégrations backend :

Attribut de déploiement
Opérateurs
Valeur d'exemple

status

eq ou neq

"ready" ou "error"

request_id

eq

"7e709a0d8efd"

dans ou nin

[ "7e709a0d8efd", "4ba353100b4b" ]

tags

eq ou neq

"tagA"

dans ou nin

[ "tagA", "tagB" ]

created_at

eq ou lte ou gte

2025-05-12T20:03:20Z

application

eq ou neq

"my-app"

dans ou nin

[ "my-app", "my-other-app" ]

version

eq ou neq

"1.0.0"

dans ou nin

[ "1.0.0", "prod" ]

fleet_name

eq ou neq

"my-app-fleet-europe"

dans ou nin

[ "fleet-eu", "fleet-us" ]

ilike

"%-eu%"

host_name

eq ou neq

"alpha-north-america-95fab093"

dans ou nin

[ "alpha-north-america-95fab093" ]

ilike

"%north-america%"

Chaque attribut peut avoir au plus 1 opérateur de filtre dans une seule requête. Voir Référence de l'API pour en savoir plus.

Triez les résultats par plusieurs champs dans l'ordre dans lequel ils apparaissent dans la requête :

Attribut de déploiement
Ordre

created_at

asc ou desc

available_session_sockets

asc ou desc

Exemples de requêtes de filtre :

Lister Déploiements en erreur pour les dépanner et les supprimer.

URL encodée :

Requête JSON formatée :

Lister Déploiements avec une version d'application obsolète pour confirmer qu'une publication est terminée.

URL encodée :

Requête JSON formatée :

N'oubliez pas d'ajouter l' Authorization en-tête avec votre jeton d'API Edgegap dans la requête.

Webhooks

Recevez de simples notifications HTTP dans le backend de votre jeu pour les changements de Déploiements en spécifiant une URL de webhook dans votre requête API de déploiement. Disponible pour :

  • À l'état Prêt : le conteneur du déploiement a démarré avec succès (le serveur commence à s'initialiser ensuite).

  • En cas d'erreur : le déploiement n'a pas pu démarrer et une Déploiements s'est produite.

  • À la terminaison : Déploiements et le serveur de jeu n'est plus joignable.

Les webhooks Ready et Error ne seront jamais déclenchés pour un même déploiement.

Exemple de payload de webhook

Les webhooks sont la méthode principale recommandée pour les intégrations personnalisées du déploiement côté backend.

Les webhooks ne sont pas retentés, et peuvent être perdus si votre backend ne traite pas la requête en raison d'une limitation de débit ou d'une erreur. Revenez à l'API Status au cas où vous ne recevriez pas de webhook dans le délai attendu.

Les webhooks suivent le cycle de vie du déploiement, mais ne connaissent pas l’état d’initialisation de votre scène/niveau. Pour suivre la progression du chargement de votre scène/niveau, implémentez un webhook personnalisé dans votre serveur de jeu.

🚨 Dépannage

Lors du dépannage des déploiements :

  1. vérifiez qu’il n’y a aucune erreur dans votre Déploiements et Déploiements,

  2. exécutez votre serveur localement pour écarter les bogues d’intégration,

  3. consultez les étapes de dépannage sur cette page,

  4. contactez-nous sur le Discord communautaire et incluez votre ID de déploiement.

Voir Déploiements pour nos recommandations sur la manière de gérer les retours de la communauté de joueurs.

Impossible de connecter les clients au serveur - La requête a expiré., La requête a expiré , Échec de connexion , ou Échec de la vérification du port.

  • Tout d’abord, assurez-vous que le déploiement est prêt, et qu'il n'y a aucune exception d’exécution ni erreur dans le journal de votre déploiement. Si votre déploiement s’est arrêté, inspectez les journaux dans notre Tableau de bord.

  • Si vous utilisez le netcode Mirror, vous devez avoir « Démarrer automatiquement le serveur » sélectionné dans votre NetworkManager , reconstruisez, poussez et redéployez votre serveur.

  • Si vous utilisez le netcode FishNet, vous devez activer « Démarrer en mode sans tête » dans votre ServerManager, reconstruisez, poussez et redéployez votre serveur.

  • Si vous utilisez le netcode Photon Fusion 2, veuillez vous assurer que votre serveur transmet l'adresse IP publique du déploiement, le port externe et le roomCode sur le serveur, et le même code de salle dans le client dans le « NeworkRunner.StartGame » paramètre StartGameArgs. L'ID de déploiement (p. ex. b63e6003b19f) est un excellent choix, car il est unique à l’échelle mondiale et facilement accessible au client par Matchmaker affectation et à la Regard approfondi.

  • Ensuite, veuillez vérifier que le réglage de port dans les paramètres netcode de la build de votre serveur correspond au port interne dans votre version de l’application. Vous pouvez modifier le mappage des ports en éditant le version de l’application sans reconstruire. Trouvez votre protocole dans votre intégration netcode.

  • Veuillez vous assurer que votre client de jeu se connecte au port externe affiché sur la page des détails de votre déploiement ; cette valeur sera toujours aléatoire pour des raisons de sécurité.

  • Si vous utilisez le protocole Secure Websocket (WSS) dans votre intégration netcode, veuillez vous assurer que votre version de l’application la configuration du port pour le WSS a la mise à niveau TLS activée.

  • Êtes-vous situé en Chine et utilisez-vous Smart Fleets? Votre connexion peut être bloquée par le Grand Pare-feu. Envisagez d'ajouter à votre flotte un serveur situé en Chine, ou d'utiliser un VPN pour vous connecter.

Mon déploiement s’est arrêté/redémarré et je ne peux plus accéder à ses journaux.

  • Si le processus du serveur plante en raison d'une exception, notre système tentera de redémarrer automatiquement le serveur. Envisagez de tester votre serveur localement pour découvrir la cause racine.

  • Nous conservons les journaux uniquement pendant la durée du déploiement ; si vous souhaitez inspecter les journaux après l’arrêt du déploiement, veuillez intégrer un stockage de journaux tiers.

  • Voir Déploiements pour découvrir toutes les causes de l’arrêt de votre déploiement.

Mon déploiement s’est arrêté automatiquement après X minutes.

  • Les déploiements du niveau gratuit ont une limite de 60 minutes ; veuillez envisager de mettre à niveau votre compte.

  • Les déploiements cloud seront interrompus après 24 heures d'exécution conformément à notre politique de nettoyage des serveurs, pour la maintenance de l'infrastructure et pour éviter d'engendrer des coûts inattendus lorsque le déploiement n'a pas été arrêté correctement. Pour les serveurs de longue durée de plus de 24 heures, envisagez d'utiliser Flottes privées avec Persistance.

  • Voir Déploiements pour découvrir toutes les causes de l’arrêt de votre déploiement.

Mon déploiement est prêt mais je ne parviens pas à m'y connecter pendant plusieurs minutes ensuite.

  • Une fois qu’un déploiement est prêt, l’initialisation de votre moteur de jeu commence. Ce processus peut prendre de quelques secondes à plusieurs minutes, et le serveur n’accepte pas les connexions des joueurs pendant cette période.

  • Envisagez d’optimiser l’initialisation de votre serveur pour réduire cette durée.

  • Les clients de jeu doivent retenter la connexion à intervalles de 1 seconde pendant une durée limitée (selon la durée de votre initialisation), après quoi ils reviennent au matchmaking.

  • Envisagez d’ajouter une scène de chargement afin que le serveur puisse effectuer l’initialisation (et le déplacement dans le cas d’Unreal Engine) en même temps que les clients, tout en synchronisant l’état des deux.

Mon appareil Meta Quest renvoie HTTP 0 : impossible de résoudre l’hôte de destination .

  • Lors de la compilation d’applications Unity pour la cible Android, votre autorisation d’accès à Internet peut être automatiquement supprimée de l’artefact APK client généré.

  • Réajoutez les autorisations dans (nécessite de reconstruire le client ensuite) :

    • Paramètres du projet / OpenXR / ⚙️ Support Meta Quest / Suppression forcée des autorisations Internet (désélectionner).

    • Paramètres du joueur / Accès à Internet (définir sur requis).

Que se passera-t-il si un joueur quitte mon déploiement ?

  • Par défaut, les serveurs ne rejettent pas les connexions des joueurs. L’authentification des joueurs dépend de vos développeurs, car de nombreuses méthodes et divers fournisseurs d’authentification des joueurs peuvent être utilisés.

  • Les clients de jeu peuvent stocker localement les informations de connexion afin de tenter une reconnexion en cas de plantage inattendu du client.

  • Pour permettre aux joueurs de rejoindre des parties en cours, envisagez d’utiliser Regard approfondi ou Sessions.

Mon serveur affiche une utilisation du CPU à 100 % après être devenu prêt.

  • Cela peut ne pas être un problème, car les moteurs de jeu ont tendance à effectuer des opérations gourmandes en CPU lors de l’initialisation du serveur. Si l’utilisation du CPU ne baisse pas 2 à 3 minutes après le démarrage du déploiement, vous devrez peut-être optimiser votre serveur ou augmenter les ressources de la version de l’application.

  • Réduire la fréquence des ticks peut avoir un impact sur l’utilisation du CPU, car le serveur effectue moins d’opérations de messagerie.

  • Si vous utilisez le netcode Mirror, vous devez avoir « Démarrer automatiquement le serveur » sélectionné dans votre NetworkManager , reconstruisez, poussez et redéployez votre serveur.

  • Si vous utilisez le netcode FishNet, vous devez activer « Démarrer en mode sans tête » dans votre ServerManager, reconstruisez, poussez et redéployez votre serveur.

  • Vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM) dans le niveau gratuit.

  • Vous pouvez augmenter les ressources allouées lors de la création d’une nouvelle version de l’application. Vous pouvez dupliquer votre version d’application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ou votre image.

Mon déploiement redémarre en boucle et affiche l’erreur `OOM kill` .

  • Ce comportement est causé par le dépassement de la quantité de mémoire allouée. Envisagez d’optimiser l’utilisation de la mémoire avec le pooling d’objets, la compression, ou en supprimant les objets inutiles dans votre scène.

  • Assurez-vous que votre projet charge la scène par défaut contenant votre NetworkManager et que la scène est incluse dans les paramètres de build de Unity.

  • Vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM) dans le niveau gratuit.

  • Vous pouvez augmenter les ressources allouées lors de la création d’une nouvelle version de l’application. Vous pouvez dupliquer votre version d’application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ou votre image.

Parfois, l'utilisation de la mémoire (RAM) de mon serveur atteint un pic très élevé, est-ce un problème ?

  • Tant que vous restez dans la quantité de mémoire allouée à la version de l’application, ce n’est pas un problème.

  • Le dépassement de la quantité de mémoire allouée à la version de l’application entraînera `OOM kill` (voir ci-dessus).

Les performances de mon serveur seront-elles affectées par d’autres serveurs fonctionnant sur la même machine ?

  • Non, notre plateforme garantit que les ressources allouées ne seront pas utilisées par d’autres studios ni par d’autres serveurs sur l’infrastructure partagée. Avec Edgegap, il n’y a pas de voisins bruyants.

PrécédentApplications et versions
SuivantFlottes privées

Mis à jour

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