> 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/orchestration/deployments.md). # Déploiements En savoir plus sur les déploiements et leur cycle de vie - concepts et bonnes pratiques pour une compréhension plus approfondie. ## 🗺️ Orchestration Démarrez de nouveaux serveurs en quelques secondes pour répondre aux besoins de capacité grâce à notre approche de calcul en périphérie native du cloud. Nous considérons les serveurs comme [du bétail plutôt que des animaux de compagnie](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/) - en remplaçant entièrement les instances défectueuses au lieu de les soigner manuellement une par une. {% hint style="info" %} Votre choix d’orchestration aura **un impact sur vos coûts DevOps, vos coûts serveurs et votre évolutivité**. {% endhint %} {% hint style="success" %} [Contactez-nous sur Discord](https://discord.gg/MmJf8fWjnt) pour en savoir plus sur les options d’orchestration hybride et optimiser vos coûts d’hébergement. {% endhint %} 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 à durée de vie courte (limitée dans le temps) se réduisent à la fin du match, offrant **le meilleur ratio coût/performance**. Les sessions sont généralement automatisées via un [Matchmaking](/fr/unity/matchmaking.md) service, qui déploie des serveurs juste à temps selon des règles strictes, et permet éventuellement de remplir les serveurs en cours de route pour [augmenter les taux de remplissage des matchs](https://edgegap.com/blog/how-session-fill-rate-affects-your-multiplayer-hosting-costs). 👍 **Avantages** * Meilleure efficacité coût - 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 notion de 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. * Montée en charge la plus rapide (capacité de pointe) en cas de pic de trafic inattendu. * Le plus haut niveau de sécurité et de prévention de la triche des joueurs (autorité du serveur). * Impact minimal d’un crash serveur inattendu sur les joueurs, n’affectant qu’un seul match. 👎 **Inconvénients** * Adopter un nouveau modèle mental d’orchestration demande un certain effort d’adaptation au départ. * Les serveurs fonctionnant plus de 24 heures seront automatiquement arrêtés. 🧩 **Particulièrement adapté pour** * Jeux sensibles à la latence - **lorsque l’optimisation du netcode ne peut pas compenser un ping élevé :** * Jeux de tir à la première personne, 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[^1], jeux de tir coopératifs, MOBA, jeux de sport, ARPG et dungeon crawlers, … {% hint style="info" %} Edgegap met automatiquement à l’échelle l’ensemble des plus de 615 emplacements de serveurs à la hausse/à la baisse selon l’activité des joueurs dans chaque région. Préparez-vous au succès - passez sans heurts [à 14 millions d’utilisateurs simultanés en 60 minutes](https://edgegap.com/resources/performance-benchmark). {% endhint %} ### Veille régionale Jeu MMO persistant de monde 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 [Server Browser](/fr/learn/server-browser.md) selon les préférences des joueurs (automatisé par région ou recherche personnalisée), avec un pré-dimensionnement horizontal du déploiement basé sur la capacité régionale. 👍 **Avantages** * Approche familière et facile à comprendre, à l’ancienne, pour les vétérans aguerris. * Le plus haut niveau de sécurité et de prévention de la triche des joueurs (autorité du 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 pointe). * 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 faible subissent un ping élevé car les serveurs sont éloignés. 🧩 **Particulièrement adapté pour** * Mondes persistants avec du contenu généré par les utilisateurs stocké sur le serveur même lorsque les joueurs sont hors ligne. * MMO, jeux bac à sable avec construction de base ou placement d’objets, extraction shooters, ... * jeux tolérants à la latence - **lorsque la physique temps réel avec autorité du serveur n’est pas requise**: * jeux mobiles, jeux coopératifs, JCC/TCG, stratégies au tour par tour, … * Multijoueur asynchrone, **où les crashs serveur ont un impact minimal sur l’expérience des joueurs :** * course contre des fantômes, piller une base ennemie, jeux de construction/culture à minuterie, … * applications avec un processus d’initialisation lourd - lorsque la préparation des serveurs prend des minutes. ### Pair à pair Déplacer les efforts de développement de ~~serveurs dédiés~~ vers **un netcode de 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, nécessitant uniquement des serveurs de relais pour résoudre la traversée NAT. * Coût DevOps le plus faible - maintenance requise uniquement pour les versions client et les canaux de distribution. * Impact minimal d’un crash serveur inattendu 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 netcode pair à pair accru nécessitant des compétences en programmation concurrente. * Les pings les plus élevés 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 perdre des sessions lorsque l’hôte part, à moins que vous n’implémentiez une migration d’hôte personnalisée. 🧩 **Particulièrement adapté pour** * Jeux coopératifs et occasionnels - **lorsque la triche ne gâche pas le plaisir ni ne casse le jeu**, * Jeux pour enfants, jeux d’exploration, aventures, … {% hint style="success" %} Découvrez nos [Relais distribués](https://docs.edgegap.com/docs/distributed-relay-manager) pour un service permettant le pair à pair avec une latence et une sécurité de premier ordre. {% endhint %} ## 📍 Placement des serveurs Quelle que soit la méthode d’orchestration choisie, sélectionner le bon emplacement de serveur pour un groupe de joueurs est essentiel 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. {% hint style="info" %} 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**. {% endhint %} {% hint style="success" %} **Edgegap déploie dans le** [**meilleur emplacement possible**](#server-score) **avec capacité disponible**, pour des matchs rapides et à faible latence. {% endhint %}
{% hint style="info" %} Voir [#deployment-balance-points](#deployment-balance-points "mention") vers **analyser le placement des serveurs en temps réel**, à grande échelle. {% endhint %} ### Score du serveur La stratégie de score du serveur utilise la méthodologie brevetée d’Edgegap, qui **optimise le placement des serveurs pour chaque match individuellement**. Elle effectue une télémétrie non intrusive pour approximer la proximité réseau de chaque joueur par rapport à nos emplacements de serveurs et choisir le serveur qui offre le meilleur : * **réactivité** - offre le ping moyen le plus faible pour tous les joueurs, * **équité** - offre un ping équilibré et équitable pour tous les joueurs. {% hint style="success" %} Notre [Matchmaker](/fr/learn/matchmaking.md) 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](https://docs.edgegap.com/api/#tag/Deployments), saisissez les adresses IP publiques des joueurs ou leurs coordonnées géographiques dans votre requête de déploiement. {% endhint %} **Placement peu réactif** - le serveur est loin, ping élevé pour tous les joueurs :
**Placement injuste** - ping inégal, un joueur est désavantagé :
**Exemple de bon placement** - ping réactif et équitable pour tous les joueurs :
{% hint style="info" %} 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 Europe, ou côte Ouest vs côte Est), ce qui est souvent le cas avec les lobbies préformés. {% endhint %} ### Géolocalisation Sinon, **fournissez les coordonnées cible de latitude et de longitude ou l’adresse IP publique d’une sonde de ping dans la région préférée**. Cette approche nécessite une implémentation supplémentaire de géorecherche côté client, reposant entièrement sur la solution du développeur. {% hint style="warning" %} Cette stratégie n'est pas recommandée pour [#match-bound](#match-bound "mention") 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. {% endhint %} {% hint style="success" %} Alternativement, laissez les joueurs **choisir un serveur persistant (toujours en ligne)** d'une liste avec [Server Browser](/fr/learn/server-browser.md). {% endhint %} ### Verrouillage régional Certains designs ou publics ne sont pas destinés à traverser vers les régions voisines pour des raisons de conformité, techniques ou opérationnelles. Pensez à [Server Browser](/fr/learn/server-browser.md) avec [des politiques de mise à l’échelle régionales](/fr/learn/server-browser.md#automated-scaling). {% hint style="warning" %} Cette stratégie n'est pas recommandée pour [#match-bound](#match-bound "mention") 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. {% endhint %} ## 🟢 Qualité de connexion Certains jeux (et certains 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 bugs de régression à grande échelle, **les joueurs peuvent manquer d’une compréhension approfondie des concepts 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, donc 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 d’assistance sur notre plateforme. {% hint style="info" %} Si vous avez besoin d’aide, [veuillez nous contacter sur Discord](https://discord.gg/MmJf8fWjnt). Pour l’assistance aux jeux en direct, consultez notre [système de tickets](https://edgegap.atlassian.net/servicedesk/customer/portal/3). {% endhint %} #### Faible latence La latence d’un joueur est une combinaison des latences liées au transfert de données entre : * **les appareils physiques -** le signal physique circulant à travers [la topologie de réseau Internet](https://en.wikipedia.org/wiki/Internet#Routing), * **hôte à hôte** - résultant des mesures de protocole, de transport et de sécurité, * **processus à processus** - résultant de l’encapsulation/le 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 plus faible. Avec des emplacements chez 17 fournisseurs cloud et bare metal, vous obtenez **un ping de premier ordre pour les joueurs partout dans le monde**. La couverture mondiale des serveurs et d’Internet (pas seulement chez Edgegap) est limitée en raison de facteurs tels que : * **la disponibilité des infrastructures** - la qualité de la connexion Internet dans une région donnée peut ne pas être suffisante, * **facteurs naturels** - des baies de serveurs très complexes nécessitent principalement un environnement stable. #### Haute disponibilité La disponibilité des serveurs dans divers emplacements à travers le monde varie au fil du temps, changeant plusieurs fois au cours de la journée. Edgegap **adapte automatiquement à la hausse/à la baisse** les emplacements **à la demande**, en tenant compte de : * **trafic de pointe** - déploiements effectués dans une période de 15 minutes, * **besoins en vCPU** - plus de vCPU par déploiement augmente la demande globale pour un emplacement spécifique, * **offre du fournisseur** - certains emplacements éloignés ont moins d’options de fournisseurs disponibles, * **disponibilité des machines** - certains emplacements peuvent n’offrir que des machines 4 vCPU ou 8 vCPU, * **demandes du studio** pour les tests, l’assurance qualité, l’accès anticipé, les bêtas fermées ou les tournois. Toutes les requêtes de déploiement des applications sont regroupées pour évaluer la demande par emplacement. Toutes les organisations ont par défaut la même priorité d’allocation, avec la **possibilité d’ajouter des pools de serveurs privés pour les clients entreprise ayant besoin de matériel ou d’emplacements spécifiques**. {% hint style="success" %} Veuillez **nous contacter pour planifier une sortie**, ou si vous avez des demandes concernant la disponibilité des emplacements. {% endhint %} #### Résolution des problèmes des joueurs Les problèmes des joueurs peuvent provenir de bugs serveur ou d’incidents chez le fournisseur, mais peuvent aussi venir de tiers tels que les FAI locaux, les services de jeu, des bugs dans des bibliothèques de bas niveau, des fournisseurs d’infrastructure ou d’autres sources. Lors du dépannage des signalements ou incidents des joueurs, tenez compte des facteurs : * **qualité du matchmaking** - les joueurs devraient être proches les uns des autres (même région) pour [#server-placement](#server-placement "mention") pour obtenir les meilleurs résultats : * voir [Matchmaking](/fr/learn/matchmaking.md) et [Balises de ping](/fr/learn/orchestration/ping-beacons.md) pour nos recommandations, * voir [Analyse approfondie](/fr/learn/matchmaking/matchmaker-in-depth.md#player-tracing) pour apprendre comment trouver les journaux de serveur liés aux signalements des joueurs, * **problèmes régionaux :** * 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. Chine, Russie) peuvent être restreintes en raison de sanctions locales, * **niveau de cache** - Edgegap donnera la priorité aux déploiements rapides dans les emplacements mis en cache : * [activez le cache pour déployer vos serveurs en quelques secondes](/fr/learn/orchestration/application-and-versions.md#other-parameters-optional), * **temps maximum de déploiement** - les déploiements peuvent échouer en raison d’un processus d’initialisation lent et lourd : * voir [Applications et versions](/fr/learn/orchestration/application-and-versions.md#safety-guardrails) pour augmenter le délai d’attente, * retardez les étapes d’initialisation jusqu’à ce qu’elles soient absolument nécessaires, * **problèmes d’image de serveur ou d’intégration**. {% hint style="success" %} **Afficher les ID de déploiement dans l’interface d’historique des matchs du client** pour tracer les signalements des joueurs lors du dépannage. {% endhint %} {% hint style="info" %} Informer les utilisateurs des bugs généralisés, des problèmes temporaires et des pannes afin d’atténuer le sentiment négatif. {% endhint %} ## 🔄 Cycle de vie du déploiement Les déploiements Edgegap passent par plusieurs étapes du cycle de vie, indiquées par le statut du déploiement. #### 1. Démarrer un déploiement Un déploiement pour **des fins de test** peut être lancé avec : * [Unreal Engine](/fr/unreal-engine.md) - extension ou plugin Docker pour les projets Unreal Engine, * [Unity](/fr/unity.md) - plugin pour les projets Unity, * [Interface Web du tableau de bord](https://app.edgegap.com/deployment-management/deployments/list) - interface web facile à utiliser pour tester l’intégration du serveur. Un déploiement pour **environnement de production en direct** doit être lancé avec : * [Matchmaking](/fr/learn/matchmaking.md) - trouver d’autres joueurs et démarrer des serveurs à la demande ([#match-bound](#match-bound "mention")). * [Server Browser](/fr/learn/server-browser.md) - préchauffer des serveurs avec une longue initialisation ([#regional-standby](#regional-standby "mention")). * [API de déploiement](https://docs.edgegap.com/api/#tag/Deployments/operation/deploy) - intégration personnalisée de serveur à serveur (mise à l’échelle personnalisée). {% hint style="success" %} **Enregistrer** `request_id` **(ID de déploiement) et étiqueter les déploiements** pour identifier et dépanner les problèmes plus tard. {% endhint %} {% hint style="info" %} Lors des tests avec [API de déploiement](https://docs.edgegap.com/api/#tag/Deployments/operation/deploy), vous pouvez remplacer le Dockerfile par défaut `CMD` par une commande personnalisée. {% endhint %} #### 2. Déploiement Une fois qu’un déploiement est lancé, notre système effectuera un certain nombre d’étapes en succession rapide : * Télémétrie - nous mesurons la réactivité réseau des centres de données disponibles pour chaque joueur, * Déploiement - nous réservons la capacité et préparons le lancement 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. {% hint style="success" %} Activer [Activer la mise en cache dans la version de votre application](/fr/learn/orchestration/application-and-versions.md#active-caching) pour déployer des serveurs en quelques secondes. {% endhint %} {% hint style="warning" %} **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](mailto:info@edgegap.com) pour planifier les sorties, estimer le trafic de lancement et préparer le succès. {% endhint %} #### 3. Déploiement prêt Votre conteneur est entièrement initialisé et votre serveur démarre maintenant. Pendant quelques secondes à une minute, votre serveur peut encore être en cours d’initialisation et ne pas répondre aux requêtes des joueurs tant que votre moteur de jeu (ou runtime personnalisé) n’est pas entièrement prêt à accepter les connexions des joueurs. {% hint style="success" %} Une fois le déploiement prêt, **réessayez la connexion du joueur jusqu’à ce qu’elle réussisse**, ou jusqu’au délai d’attente client prédéfini. {% endhint %} {% hint style="danger" %} **La gestion des plantages du serveur dépend de votre** [**politique de redémarrage du processus**](/fr/learn/orchestration/application-and-versions.md#safety-guardrails)**.** [L'état du serveur peut être perdu](/fr/learn/orchestration/persistance.md#state-management). {% endhint %} Selon la [Applications et versions](/fr/learn/orchestration/application-and-versions.md#active-caching) configuration de la version, vous pouvez recevoir : 🟢 **Cache trouvé** 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 obtenir des déploiements systématiquement rapides dans le monde entier. 🔴 **Cache manqué** 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 « exiger des emplacements mis en cache » 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 à tout moment se retrouver dans l’état Non traitable, pour des raisons inattendues. Cela est plus susceptible d’arriver lors des tests de votre intégration ou 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 : * Vérifiez l’état du service Edgegap avec [notre page de surveillance de la disponibilité](https://status.edgegap.com/). * Essayez de tester votre conteneur serveur localement avec Docker Desktop pour exclure les problèmes Edgegap. {% hint style="info" %} Si vous avez besoin d’aide, [veuillez nous contacter sur Discord](https://discord.gg/MmJf8fWjnt). Pour l’assistance aux jeux en direct, consultez notre [système de tickets](https://edgegap.atlassian.net/servicedesk/customer/portal/3). {% endhint %} {% hint style="success" %} **Lorsque vous demandez de l’aide,** **incluez votre ID de déploiement et tous les détails utiles** afin que nous puissions enquêter rapidement ! {% endhint %} #### 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 pour éviter d’encourir des coûts inattendus lorsque le déploiement n’a pas été correctement arrêté. Pour les serveurs longue durée de plus de 24 heures, envisagez d’utiliser [flottes privées](/fr/learn/orchestration/flottes-privees.md) avec [Persistance](/fr/learn/orchestration/persistance.md). Optimisez vos coûts et arrêtez tôt les déploiements inactifs à l’aide des méthodes suivantes : * **Version de l’application** [**Politique de redémarrage**](/fr/learn/orchestration/application-and-versions.md#safety-guardrails) - empêcher le redémarrage automatique à l’arrêt ou en cas de crash. * **Durée maximale du jeu** - le temps alloué dans votre [Applications et versions](/fr/learn/orchestration/application-and-versions.md#safety-guardrails) a expiré. * **Arrêt automatique via** [**DELETE\_URL**](/fr/learn/orchestration/deployments.md#injected-environment-variables) - 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](/fr/unreal-engine.md#stop-deployments) et [Unity](/fr/unity.md#stop-deployments) guides pour les utilitaires SDK et une intégration facile. * **Arrêt depuis un backend personnalisé** - votre orchestration de session personnalisée peut utiliser [API des déploiements](https://docs.edgegap.com/api/#tag/Deployments/operation/deployment-delete). * [flottes privées](/fr/learn/orchestration/flottes-privees.md) L’hôte exécutant votre déploiement a été supprimé via une action planifiée. {% hint style="info" %} Une fois qu’un déploiement est arrêté, **nous déclenchons une terminaison gracieuse** en envoyant `SIGTERM` signal à votre processus principal, en permettant une courte période de terminaison. Une fois expirée, un `SIGKILL` signal est envoyé pour arrêter le déploiement. {% endhint %} ## 👀 Observabilité Permettre aux serveurs de jeu d’interopérer avec des tiers et d’obtenir des informations opérationnelles. ### Découvrabilité Une fois prêt, le déploiement se voit attribuer une URL ([fqdn](https://en.wikipedia.org/wiki/Fully_qualified_domain_name)) et un port externe pour chaque port interne. {% hint style="success" %} Utilisez **des étiquettes de déploiement (jusqu’à 40 caractères) pour marquer facilement vos déploiements** et [#filter-deployments](#filter-deployments "mention"). {% endhint %} {% hint style="info" %} **Le trafic sortant (vers les clients ou le backend) depuis vos serveurs de jeu n’est jamais bloqué** ou filtré. {% endhint %} #### **WebSockets (WS) et WebSockets sécurisés (WSS)** Pour utiliser un netcode basé sur websocket avec Edgegap, vous avez deux options : * **certificat géré**, configuré en 1 minute sans écrire de code : * configurez votre [Applications et versions](/fr/learn/orchestration/application-and-versions.md) vers **utilisez Websocket (WS) et activez la mise à niveau TLS,** * utilisez l’URL Edgegap pour connecter les clients (par ex. `https://5fa53fa00a57.pr.edgegap.net/`) * **certificat auto-géré**, si vous souhaitez utiliser votre propre domaine personnalisé : * configurez votre [Applications et versions](/fr/learn/orchestration/application-and-versions.md) vers **utilisez le WebSocket sécurisé (WSS)**, * configurez votre propre flux de certificat TLS avec un enregistrement DNS personnalisé (par ex. sur [Cloudflare](https://www.cloudflare.com/application-services/products/ssl/)). {% hint style="danger" %} Les exceptions serveur non interceptées feront redémarrer le conteneur du déploiement et invalideront la sécurité TLS. Dans ce cas, [arrêtez votre serveur](#id-5.-deployment-stopped) et [rematcher les joueurs sur un nouveau déploiement](/fr/learn/matchmaking.md#custom-lobby). [L'état du serveur peut être perdu](/fr/learn/orchestration/persistance.md#state-management). {% endhint %} ### Variables injectées Les serveurs de jeu ont souvent besoin d'informations supplémentaires, comme l'adresse IP du serveur, les valeurs des ports internes ou autres. L'injection de variables d'environnement en lecture seule est une manière fiable et indépendante du cloud de transmettre des paramètres. {% hint style="success" %} Récupérez les valeurs des variables avec [GetEnvironmentVariable en C#](https://learn.microsoft.com/en-us/dotnet/api/system.environment.getenvironmentvariable?view=net-8.0) ou [GetEnvironmentVariable en C++](https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Core/GenericPlatform/FGenericPlatformMisc/GetEnvironmentVariable). {% endhint %} {% hint style="info" %} Voir [Variables de version de l’application](/fr/learn/orchestration/application-and-versions.md#injected-variables) et [Variables du matchmaking](/fr/learn/matchmaking/matchmaker-in-depth.md#injected-variables) en plus des variables de déploiement ci-dessous. {% endhint %} #### **Variables personnalisées** Définissez jusqu'à 20 variables personnalisées pour chaque déploiement, chacune contenant jusqu'à 4 Ko de données de chaîne. {% hint style="warning" %} **Évitez d'utiliser les noms réservés (ci-dessous), sinon vos variables personnalisées seront écrasées !** {% endhint %} Accédez aux informations importantes en lisant les variables injectées à vos serveurs par Edgegap : #### **Identifiants** * **`ARBITRIUM_REQUEST_ID`** - par ex. `f68e011bfb01` . * ID de déploiement unique, également appelé ID de requête. Utilisé pour récupérer plus d'informations. * Les URL de déploiement ont toujours la forme `{ARBITRIUM_REQUEST_ID}.pr.edgegap.net`. * **`ARBITRIUM_PUBLIC_IP`** - par 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`** - par ex. `alpha-north-america-70364ef8` . * Identifiant unique de la machine hébergeant votre déploiement, partagé avec d'autres déploiements. * **`ARBITRIUM_DEPLOYMENT_TAGS`** - par ex. `tag1,tag2` . * Balises de déploiement définies par l'utilisateur et séparées par des virgules, [utiles pour faciliter la recherche et le filtrage](#filter-deployments). * **`ARBITRIUM_PRIVATE_FLEET_ID`** - par ex. `PUBLIC_CLOUD` , ou ID de flotte si hébergé sur [flottes privées](/fr/learn/orchestration/flottes-privees.md). #### Spécifications des ressources * **`ARBITRIUM_HOST_IN_PRIVATE_FLEET`** - par ex. `false` , indiquant s'il est hébergé sur [flottes privées](/fr/learn/orchestration/flottes-privees.md). * **`ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY`** - par ex. `2000` , fréquence du processeur en MHz. * **`ARBITRIUM_DEPLOYMENT_VCPU_UNITS`** - par ex. `256`, unités vCPU allouées (1024 = 1 vCPU). * **`ARBITRIUM_DEPLOYMENT_MEMORY_MB`** - par ex. `512`, RAM allouée en Mo (1024 = 1 Go). #### **Gestion du cycle de vie** * **`ARBITRIUM_DELETE_URL`** - par ex. `https://api.edgegap.com/v1/self/stop/9f511e17/660`. * Appelable depuis le déploiement, [le déploiement sera arrêté proprement](#id-5.-deployment-stopped). * Nécessite un jeton unique à usage unique `ARBITRIUM_DELETE_TOKEN` dans `Authorization` en-tête. * **`ARBITRIUM_DELETE_TOKEN`** - par ex. `7df4cd933df87084b34ae80d8abde293`. * **`ARBITRIUM_CONTEXT_URL`** - par ex. `https://api.edgegap.com/v1/context/9170f5211e17/17`. * Appelable uniquement depuis le déploiement, renvoie davantage de détails sur le déploiement. * Nécessite un `ARBITRIUM_CONTEXT_TOKEN` dans `Authorization` en-tête. * **`ARBITRIUM_CONTEXT_TOKEN`** - par ex. `dfaf50b9333b9ee07b22ed247e4a17e6`. #### **Découvrabilité** * **`ARBITRIUM_PORT_GAMEPORT_INTERNAL`** - par ex. `7777` , port interne pour l'écoute du serveur. * **`ARBITRIUM_PORT_GAMEPORT_EXTERNAL`** - par ex. `31504` , port externe pour les connexions client. * Les valeurs des ports externes sont randomisées pour chaque déploiement à des fins de sécurité. * **`ARBITRIUM_PORT_GAMEPORT_PROTOCOL`** - par ex. `UDP` , protocole de votre transport netcode. {% hint style="success" %} Les exemples supposent que vous avez nommé votre port `gameport` (par défaut). **Chaque port ajoute un ensemble supplémentaire de variables épurées** [Applications et versions](/fr/learn/orchestration/application-and-versions.md#port-mapping) **variables :** `@Super Port!` ⇒ `ARBITRIUM_PORT_SUPER_PORT_INTERNAL` . {% endhint %} * **`ARBITRIUM_BEACON_ENABLED`** - par ex. `true`, si vous déployez sur [flottes privées](/fr/learn/orchestration/flottes-privees.md) avec [Balises de ping](/fr/learn/orchestration/ping-beacons.md). * **`ARBITRIUM_HOST_BEACON_PUBLIC_IP`** - par ex. `139.177.198.69` , IP publique du beacon le plus proche. * **`ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL`** - par ex. `30199`, pour la mesure du ping via UDP. * **`ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL`** - par ex. `30456`, pour la mesure du ping via TCP. #### **Informations structurées (JSON sous forme de chaîne)** {% hint style="info" %} 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. {% endhint %}
ARBITRIUM_DEPLOYMENT_LOCATION:
- Informations détaillées sur l'emplacement du déploiement. ```json ARBITRIUM_DEPLOYMENT_LOCATION="{ "city": "Montréal", "country": "Canada", "continent": "Amérique du Nord", "administrative_division": "Québec", "timezone": "heure de l'Est", "latitude": 45.513707, "longitude": -73.619073 }" ```
ARBITRIUM_PORTS_MAPPING:
- Informations détaillées sur vos ports internes et externes. ```json ARBITRIUM_PORTS_MAPPING="{ "ports": { "gameport": { "name": "Port de jeu", "internal": 7777, "external": 31504, "protocol": "UDP" }, "webport": { "name": "Port Web", "internal": 8888, "external": 31553, "protocol": "TCP" } } }" ```
### Supervision du tableau de bord Notre [Tableau de bord](https://app.edgegap.com/) fournit des outils pour surveiller la scalabilité de votre serveur et faciliter les opérations. #### Analyses {% hint style="success" %} Retrouvez [les tableaux de bord analytiques dans le menu latéral](https://app.edgegap.com/analytics/dashboards/list) sous la catégorie Hébergement et orchestration de serveurs. {% endhint %} :star2: [**Passez au niveau Paiement à l'utilisation**](https://app.edgegap.com/user-settings?tab=memberships) **pour débloquer des métriques et des analyses détaillées des performances du serveur :** * **Analyses générales :** suivez les versions déployées avec le nombre de serveurs en direct par version + aperçu de l'utilisation des ressources, * **Analyses CPU**: dépannez les serveurs lents en raison d'opérations gourmandes en processeur, * **Analyses mémoire**: réduisez les redémarrages du serveur dus au dépassement de la mémoire allouée, * **Analyses réseau :** détectez des schémas réseau inefficaces et optimisez le netcode.
#### Carte de déploiement {% hint style="success" %} Retrouvez la carte de déploiement dans [la page des détails de votre déploiement dans le tableau de bord](https://app.edgegap.com/deployment-management/deployments/list). {% endhint %} 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 {% hint style="success" %} Retrouvez la carte thermique des points d'équilibre du déploiement dans [la page des détails de votre application dans le tableau de bord](https://app.edgegap.com/application-management/applications/list). {% endhint %} Prévisualisez la carte thermique des points d'équilibre du déploiement et filtrez par [Applications et versions](/fr/learn/orchestration/application-and-versions.md). Les points d'équilibre sont des emplacements approximatifs offrant une proximité réseau équivalente avec chaque joueur dans un déploiement donné :
{% hint style="warning" %} Les foyers de points d'équilibre dans des lieux inhabituels (p. ex. le Groenland) indiquent un matchmaking de joueurs éloignés les uns des autres. En savoir plus sur [#connection-quality](#connection-quality "mention") et [Balises de ping](/fr/learn/orchestration/ping-beacons.md) pour optimiser votre matchmaking. {% endhint %} #### Journaux de déploiement {% hint style="success" %} Retrouvez les journaux de déploiement dans [la page des détails de votre déploiement dans le tableau de bord](https://app.edgegap.com/deployment-management/deployments/list). {% endhint %} Les journaux de déploiement affichent des informations sur [#deployment-lifecycle](#deployment-lifecycle "mention"):
#### Journaux du conteneur {% hint style="success" %} Retrouvez les journaux du conteneur dans [la page des détails de votre déploiement dans le tableau de bord](https://app.edgegap.com/deployment-management/deployments/list). {% endhint %} Inspectez les journaux de votre serveur de jeu en cas de problème ou lors du débogage :
{% hint style="warning" %} **Une fois le déploiement arrêté, les journaux du conteneur sont supprimés.** Configurez [un stockage S3 de journaux tiers](/fr/docs/endpoint-storage.md) pour enregistrer les journaux. {% endhint %} #### Métriques du conteneur {% hint style="success" %} Retrouvez les métriques du conteneur dans [la page des détails de votre déploiement dans le tableau de bord](https://app.edgegap.com/deployment-management/deployments/list). {% endhint %} Consultez les métriques du conteneur (processeur, mémoire, réseau) pour : * identifier les problèmes de connexion courants lorsque [#troubleshooting](#troubleshooting "mention"), * 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 de valeurs sur une période d'une minute, disponibles dans le niveau gratuit. :star2: [**Passez au niveau Paiement à l'utilisation**](https://app.edgegap.com/user-settings?tab=memberships) **pour débloquer des métriques précises avec des intervalles d'une seconde.**
{% hint style="info" %} [Contactez-nous](mailto:info@edgegap.com) avant votre lancement pour demander une assistance d'hébergement en direct pour les lancements à grande échelle. {% endhint %} ### Contexte et statut Des informations supplémentaires sur le déploiement peuvent être récupérées au format JSON : * depuis l'intérieur du déploiement (serveur de jeu), en utilisant [API de contexte de déploiement](https://docs.edgegap.com/api/#tag/Context/operation/context-get), * depuis l'extérieur du déploiement (backend / tiers), en utilisant [API d'état de déploiement](https://docs.edgegap.com/api/#tag/Deployments/operation/deployment-status-get). {% hint style="info" %} L'API de contexte (depuis le déploiement) nécessite un jeton d'API de contexte, tandis que l'API d'état utilise votre jeton Edgegap. {% endhint %} {% hint style="danger" %} **Trop de requêtes 429 - Les API de contexte et d'état sont limitées à 20 requêtes/s par organisation.** {% endhint %} {% hint style="success" %} **Utilisez** [#webhooks](#webhooks "mention") **pour les automatisations (matchmaking personnalisé) afin d'éviter la limitation de débit et d'assurer la scalabilité.** Les API de contexte et d'état sont destinées uniquement au développement, à l'assurance qualité et au dépannage. {% endhint %} ### Filtrer les déploiements Pour rechercher rapidement parmi tous les déploiements, vous pouvez [utiliser notre tableau de bord](https://app.edgegap.com/deployment-management/deployments/list):
{% hint style="success" %} Alternativement, laissez les joueurs **choisir un serveur persistant (toujours en ligne)** d'une liste avec [Server Browser](/fr/learn/server-browser.md). {% endhint %} [Lister les déploiements avec l'API](https://docs.edgegap.com/api/#tag/Deployments/operation/deployments-get) et appliquer des filtres avec des intégrations backend :
Attribut de déploiementOpérateursValeur d'exemple
statuseq ou neq"ready" ou "error"
request_ideq "7e709a0d8efd"
dans ou nin[ "7e709a0d8efd", "4ba353100b4b" ]
tagseq ou neq"tagA"
dans ou nin[ "tagA", "tagB" ]
created_ateq ou lte ou gte2025-05-12T20:03:20Z
applicationeq ou neq"my-app"
dans ou nin[ "my-app", "my-other-app" ]
versioneq ou neq"1.0.0"
dans ou nin[ "1.0.0", "prod" ]
fleet_nameeq ou neq"my-app-fleet-europe"
dans ou nin[ "fleet-eu", "fleet-us" ]
ilike"%-eu%"
host_nameeq ou neq"alpha-north-america-95fab093"
dans ou nin[ "alpha-north-america-95fab093" ]
ilike"%north-america%"
{% hint style="info" %} Chaque attribut peut avoir au maximum 1 opérateur de filtre dans une seule requête. Voir [Référence de l'API](/fr/docs/api.md) pour en savoir plus. {% endhint %} Triez les résultats par plusieurs champs dans l'ordre où ils apparaissent dans la requête : | Attribut de déploiement | Ordre | | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | [`created_at`](#id-1.-start-a-deployment) | [`asc`](#user-content-fn-11)[^11] ou [`desc`](#user-content-fn-12)[^12] | | [`available_session_sockets`](broken://pages/dd71be7f2a95f8fbefe2dda78022306ba0259251) | [`asc`](#user-content-fn-13)[^13] ou [`desc`](#user-content-fn-14)[^14] | Exemples de requêtes de filtre :
Liste Déploiements en erreur pour les dépanner et les supprimer. URL encodée : ``` https://api.edgegap.com/v1/deployments?query={"filters":[{"field":"status","operator":"eq","value":"error"},{"field":"application","operator":"eq","value":"my-app"},{"field":"version","operator":"eq","value":"green"}],"order_by":[{"field":"created_at","order":"desc"}]} ``` Requête JSON formatée : ```json { "filters": [ { "field": "status", "operator": "eq", "value": "error" }, { "field": "application", "operator": "eq", "value": "my-app" }, { "field": "version", "operator": "eq", "value": "green" } ], "order_by": [ { "field": "created_at", "order": "desc" } ] } ```
Liste Déploiements avec une version d'application obsolète pour confirmer qu'une mise en production est terminée. URL encodée : ``` https://api.edgegap.com/v1/deployments?query={"filters":[{"field":"status","operator":"eq","value":"ready"},{"field":"application","operator":"eq","value":"my-app"},{"field":"version","operator":"eq","value":"blue"}],"order_by":[{"field":"created_at","order":"desc"}]} ``` Requête JSON formatée : ```json { "filters": [ { "field": "status", "operator": "eq", "value": "ready" }, { "field": "application", "operator": "eq", "value": "my-app" }, { "field": "version", "operator": "eq", "value": "blue" } ], "order_by": [ { "field": "created_at", "order": "desc" } ] } ```
{% hint style="success" %} N'oubliez pas d'ajouter l' `Authorization` en-tête avec votre jeton d'API Edgegap dans la requête. {% endhint %} ### Webhooks Recevez de simples notifications HTTP dans le backend de votre jeu pour les changements de [#deployment-lifecycle](#deployment-lifecycle "mention") en spécifiant une URL de webhook dans votre [requête API de déploiement](/fr/docs/api/serveurs-dedies.md#post-deployments). Disponible pour : * Lorsqu'il est prêt : le conteneur de déploiement [a démarré avec succès](#id-1.-start-a-deployment) (le serveur commence l'initialisation après cela), * En cas d'erreur : le déploiement n'a pas pu être démarré et une [#id-4.-deployment-error](#id-4.-deployment-error "mention") s'est produite, * À la terminaison : [#id-5.-deployment-stopped](#id-5.-deployment-stopped "mention") et le serveur de jeu n'est plus joignable. Les webhooks Ready et Error ne seront jamais déclenchés pour le même déploiement.
Exemple de charge utile de webhook ```json { "request_id": "f68e011bfb01", "application": "my-game-server", "version": "2024.01.30-16.23.00-UTC", "fqdn": "f68e011bfb01.pr.edgegap.net", "public_ip": "162.254.141.66", "deployed_at": "2026-02-10T20:35:48Z", "termination_scheduled_at": "2026-02-10T21:35:48Z", "ports": { "gameport": { "external": 31504, "internal": 7777, "protocol": "UDP", "name": "gameport", "tls_upgrade": false, "link": "f68e011bfb01.pr.edgegap.net:31504", "proxy": null } }, "location": { "city": "Montréal", "country": "Canada", "continent": "Amérique du Nord", "administrative_division": "Québec", "timezone": "heure de l'Est", "latitude": 45.513707, "longitude": -73.619073 }, "tags": [ "tag1", "tag2" ], "host_id": "alpha-north-america-70364ef8", "host_in_private_fleet": false, "private_fleet_id": "PUBLIC_CLOUD", "vcpu_units": 256, "memory_mib": 512 } ```
{% hint style="success" %} **Les webhooks sont la méthode principale recommandée pour les intégrations personnalisées de déploiement côté backend.** {% endhint %} {% hint style="warning" %} **Les webhooks ne sont pas réessayés**, et peut être perdu 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 prévu. {% endhint %} {% hint style="info" %} Les webhooks observent le cycle de vie du déploiement, mais ne connaissent pas l'état d'initialisation de votre scène/niveau. Pour observer la progression du chargement de votre scène/niveau, implémentez un webhook personnalisé dans votre serveur de jeu. {% endhint %} ## 🚨 Dépannage Lors du dépannage des déploiements : 1. vérifiez qu'il n'y a aucune erreur dans votre [#deployment-logs](#deployment-logs "mention") et [#container-logs](#container-logs "mention"), 2. exécutez votre serveur en local pour exclure les bugs d'intégration, 3. consultez les étapes de dépannage sur cette page, 4. contactez-nous sur [Discord de la communauté](https://discord.gg/MmJf8fWjnt) et indiquez votre ID de déploiement. {% hint style="info" %} Voir [#player-issue-resolution](#player-issue-resolution "mention") pour nos recommandations sur la gestion des retours de la communauté des joueurs. {% endhint %}
Impossible de connecter les clients au serveur - Délai de la requête dépassé., Délai d'attente dépassé , Échec de la connexion , ou La vérification du port a échoué. * 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 votre journal de déploiement. Si votre déploiement s'est arrêté, examinez les journaux dans notre [Tableau de bord](https://app.edgegap.com/deployment-management/deployments/list). * Si vous utilisez le netcode Mirror, vous devez avoir ["Auto Start Server"](https://mirror-networking.gitbook.io/docs/hosting/edgegap-hosting-plugin-guide#build-and-push) sélectionné dans votre `NetworkManager` , reconstruisez, poussez et redéployez votre serveur. * Si vous utilisez le netcode FishNet, vous devez activer [“Start on Headless”](https://fish-networking.gitbook.io/docs/manual/components/managers/server-manager#settings-are-general-settings-related-to-the-servermanager) 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'IP publique du déploiement, le port externe et le `roomCode` sur le serveur, ainsi que le même code de salle dans le client dans le [“NeworkRunner.StartGame”](https://doc.photonengine.com/fusion/current/manual/network-runner#creating-or-joining-a-room) paramètre `StartGameArgs`. L'ID de déploiement (par ex. `b63e6003b19f`) est un excellent choix, car il est unique à l'échelle mondiale et facilement accessible au client via [Matchmaker](/fr/learn/matchmaking/matchmaker-in-depth.md) l'attribution et au [Analyse approfondie](/fr/learn/matchmaking/matchmaker-in-depth.md#injected-environment-variables). * Ensuite, veuillez vérifier que le paramètre de port dans les paramètres de netcode de la build de votre serveur correspond au port interne de votre [version de l'application](https://app.edgegap.com/application-management/applications/list). Vous pouvez modifier le mappage des ports en éditant le [version de l'application](https://app.edgegap.com/application-management/applications/list) sans reconstruire. Trouvez votre protocole dans votre intégration de 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 randomisée pour des raisons de sécurité. * Si vous utilisez le protocole Secure WebSocket (WSS) dans votre intégration de netcode, veuillez vous assurer que votre [version de l'application](https://app.edgegap.com/application-management/applications/list) configuration du port WSS a la mise à niveau TLS activée. * Êtes-vous en Chine et utilisez-vous [Smart Fleets](https://docs.edgegap.com/docs/deployment/session/fleet-manager/fleet)? 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 n'ai plus accès à ses journaux. * Si le processus du serveur plante à cause d'une exception, notre système tentera de redémarrer automatiquement le serveur. Envisagez de tester votre serveur en local pour identifier la cause racine. * Nous ne conservons les journaux que pendant la durée du déploiement ; si vous souhaitez les consulter après l'arrêt du déploiement, veuillez [intégrer un stockage de journaux tiers](https://docs.edgegap.com/docs/deployment/endpoint-storage). * Voir [#id-5.-deployment-stopped](#id-5.-deployment-stopped "mention") 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 terminé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 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](/fr/learn/orchestration/flottes-privees.md) avec [Persistance](/fr/learn/orchestration/persistance.md). * Voir [#id-5.-deployment-stopped](#id-5.-deployment-stopped "mention") 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 à me connecter pendant plusieurs minutes après. * 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 afin de réduire cette durée. * Les clients de jeu devraient réessayer la connexion à intervalles d'une 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 travel dans le cas d'Unreal Engine) en même temps que les clients, tout en synchronisant l'état des deux.
Mon appareil Meta Quest affiche HTTP 0 : impossible de résoudre l'hôte de destination . * Lors de la création d'applications Unity pour la cible Android, votre autorisation d'accès à Internet peut être automatiquement supprimée de l'artefact de build APK du client en sortie. * Rajoutez les autorisations dans (nécessite ensuite de reconstruire le client) : * Paramètres du projet / OpenXR / :gear: Prise en charge Meta Quest / Forcer la suppression des autorisations Internet (décochez). * 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 de nombreux 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 crash inattendu du client. * Pour permettre aux joueurs de rejoindre une partie en cours, envisagez d'utiliser [Analyse approfondie](/fr/learn/matchmaking/matchmaker-in-depth.md#backfill) ou [Sessions](https://docs.edgegap.com/docs/deployment/session).
Mon serveur affiche une utilisation du CPU de 100 % après être devenu prêt. * Cela ne constitue peut-être pas un problème, car les moteurs de jeu ont tendance à effectuer des opérations gourmandes en CPU pendant l'initialisation du serveur. Si l'utilisation du CPU ne baisse pas après 2 à 3 minutes suivant le démarrage du déploiement, il peut être nécessaire d'optimiser votre serveur ou d'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 ["Auto Start Server"](https://mirror-networking.gitbook.io/docs/hosting/edgegap-hosting-plugin-guide#build-and-push) sélectionné dans votre `NetworkManager` , reconstruisez, poussez et redéployez votre serveur. * Si vous utilisez le netcode FishNet, vous devez activer [“Start on Headless”](https://fish-networking.gitbook.io/docs/manual/components/managers/server-manager#settings-are-general-settings-related-to-the-servermanager) 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 de l'application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ni 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 la suppression des 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 compilation 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 de l'application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ni votre image.
Parfois, l'utilisation de la mémoire (RAM) de mon serveur atteint un pic élevé ; est-ce un problème ? * Tant que vous restez dans la limite de mémoire allouée à la version de l'application, ce n'est pas un problème. * Dépasser la quantité de mémoire allouée à la version de l'application entraînera un \`OOM kill\` (voir ci-dessus).
Les performances de mon serveur seront-elles affectées par d'autres serveurs exécutés 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 une infrastructure partagée. Avec Edgegap, il n'y a pas de voisins bruyants.
[^1]: les sessions peuvent durer jusqu’à 24 heures [^2]: égal à [^3]: différent de [^4]: request\_id (ID de déploiement) [^5]: dans le tableau [^6]: pas dans le tableau [^7]: inférieur ou égal à [^8]: supérieur ou égal à [^9]: dans le tableau [^10]: correspondance de motif insensible à la casse : * utilisez `%` pour n'importe quelle séquence * utilisez `_` pour n'importe quel caractère [^11]: croissant, plus ancien d'abord [^12]: décroissant, plus récent d'abord [^13]: croissant, complet d'abord [^14]: décroissant, vide d'abord