Structure des channels Metin2 : cores et logique des ports

Lorsqu'on installe un serveur Metin2 pour la première fois, le sujet le plus déroutant est la structure des channels Metin2 : la liste « Channel 1, Channel 2, Channel 3 » que voit le joueur est en réalité servie par combien de processus en arrière-plan, quelle map tourne sur quel core, et comment les ports sont-ils répartis ? Dans cet article, j'explique la différence entre un channel et un core, le rôle des serveurs auth et db, ainsi que l'agencement des ports d'un serveur multi-channel classique avec des exemples concrets.

La différence entre un channel et un core

Beaucoup pensent qu'un « channel » et un « core » sont la même chose, mais ce sont des couches différentes. Un channel est une division logique que le joueur voit sur l'écran de sélection : voyez-le comme plusieurs copies du même monde servant à répartir la charge. Chaque channel contient toutes les maps (villages, zones de chasse, donjons).

Un core à l'intérieur d'un channel est en revanche un processus distinct qui fait tourner un sous-ensemble des maps. Un seul processus game ne porte pas toutes les maps ; celles-ci sont réparties entre les cores. Par exemple, si un channel possède quatre cores, les villages de départ peuvent tourner sur le core1, les zones de chasse de niveau moyen sur le core2, et les maps de haut niveau et les donjons sur le core3 et le core4. Quand un joueur passe d'une map à une autre, un transfert a lieu entre les cores, mais le joueur ne le remarque jamais.

Le rôle des serveurs auth et db

Une installation multi-channel comporte deux pièces centrales :

• auth : le serveur qui valide les connexions de compte. Le client s'y connecte d'abord, l'identifiant/mot de passe est vérifié et un jeton de session est produit. L'auth est généralement un processus game dédié tournant sur son propre port avec son propre fichier CONFIG.
• db : le serveur de cache de base de données auquel tous les cores se connectent en commun. Les données comme les personnages, l'inventaire et les guildes vivent dans MySQL, mais les cores ne lui parlent pas directement : ils passent par le processus db. Cela garde les données synchronisées, de sorte que le personnage d'un joueur reste cohérent lorsqu'il passe d'un core à un autre.

La chaîne de connexion ressemble donc à ceci : client → auth (connexion) → le core du channel choisi → et tous les cores en arrière-plan → db → MySQL. Il n'y a jamais qu'un seul serveur auth et un seul db ; ce sont les cores qui sont répliqués.

Logique des ports et CONFIG

Chaque core est démarré avec un fichier CONFIG dans son propre dossier, qui définit le port sur lequel il écoute, le channel auquel il appartient et le port P2P qu'il utilise pour la communication inter-cores. Un schéma de ports cohérent simplifie grandement les choses. Une convention courante est :

• Cores du channel 1 : 13001, 13002, 13003, 13004
• Cores du channel 2 : 13011, 13012, 13013, 13014
• Cores du channel 3 : 13021, 13022, 13023, 13024
• auth : un port distinct comme 11002 — db : un port distinct comme 15000

L'important est que le schéma n'entre pas en conflit et reste logique ; les nombres en eux-mêmes sont arbitraires. Un fichier CONFIG de core typique ressemble en gros à ceci :

HOSTNAME: channel1
CHANNEL: 1
BIND_IP: 0.0.0.0
PORT: 13001
P2P_PORT: 13991
PLAYER_SQL: localhost player root motdepasse
COMMON_SQL: localhost common root motdepasse
LOG_SQL: localhost log root motdepasse
TABLEPOSTFIX: _
DB_ADDR: 127.0.0.1
DB_PORT: 15000

Ici, PORT est le port de jeu auquel les joueurs se connectent, tandis que P2P_PORT sert à parler aux autres cores du même channel. DB_ADDR et DB_PORT indiquent au core comment atteindre le processus db. Le CONFIG du processus auth porte en plus un réglage le marquant comme serveur d'authentification et est généralement lancé avec un numéro de channel spécial (par exemple 99).

Répartir les maps entre les cores

Les maps qu'un core charge sont déterminées par la liste de maps côté serveur. Chaque core ne charge que les dossiers de maps qui lui sont assignés ; les maps non assignées sont considérées comme « distantes » pour ce core. Lorsqu'un joueur arrive sur une map qui n'est pas sur un core donné, il est transféré via le lien P2P vers le core qui héberge cette map. En planifiant la répartition, surveillez deux choses :

• Équilibre de charge : n'entassez pas les zones de chasse les plus fréquentées sur un seul core ; répartissez la densité de joueurs entre les cores.
• Cohérence : n'assignez jamais la même map à deux cores différents. Chaque map doit tourner sur un seul core, sinon le transfert échoue.

En pratique, les villages de départ et les places principales constamment bondées ont généralement leur propre core, afin qu'une foule dans une zone de chasse n'affecte pas les performances de la ville.

Ordre de démarrage et gestion des processus

L'ordre de démarrage des processus du serveur est important, car les cores tentent de se connecter à db au lancement. Le bon ordre est :

1. Le service MySQL (base de données) doit être en cours d'exécution.
2. Le processus db est démarré.
3. Le processus auth est démarré.
4. Les cores des channels sont démarrés un par un.

Comme suivre les processus à la main est fatigant, la plupart des admins utilisent un simple script de démarrage. Un exemple d'approche par script de contrôle :

#!/bin/sh
# chaque core est demarre depuis son propre dossier
for dir in db auth ch1_core1 ch1_core2 ch1_core3 ch1_core4; do
    cd "/usr/metin2/$dir" && ./game &
done

Quand un core plante, il laisse généralement un core dump (un fichier core) ; vous pouvez l'inspecter avec gdb pour voir dans quelle fonction il a sauté. C'est pourquoi exécuter les cores sous screen ou un gestionnaire de services et garder les logs séparés est salvateur en cas de problème.

De combien de cores avez-vous besoin ?

Il n'y a pas de réponse fixe ; cela dépend du nombre de joueurs et du matériel. Comme chaque processus game tourne en grande partie sur un seul thread, augmenter le nombre de cores sur un serveur multi-cœurs permet de mieux exploiter le CPU. Un point de départ général : pour un petit serveur, 2 cores par channel suffisent, tandis qu'un serveur bondé bénéficie de 4 cores par channel et de plusieurs channels. Commencez avec 1 channel + 2 cores, puis ajoutez channels et cores à mesure que la base de joueurs grandit.

Questions fréquentes

Puis-je augmenter le nombre de channels plus tard ?

Oui. Ajouter un nouveau channel revient à créer des fichiers CONFIG pour les cores de ce channel, à assigner des ports sans conflit et à mettre à jour la liste de serveurs que voit le client. Comme la base de données reste partagée, les personnages sont identiques sur tous les channels.

Les joueurs peuvent-ils choisir leur channel ?

Oui, après la connexion, le joueur choisit dans la liste des channels. Comme les channels partagent le même monde, les personnages et objets ne changent pas ; seule la copie du serveur sur laquelle vous jouez change. C'est le principal moyen de répartir la charge aux heures de pointe.

Puis-je fusionner auth et db en un seul processus ?

D'un point de vue architectural, il est correct, et recommandé, de les garder séparés. db est la couche de données partagée pour tous les cores tandis qu'auth ne gère que la connexion ; les garder distincts offre une structure bien plus gérable, tant pour la sécurité que pour le débogage.

Vous voulez bâtir l'architecture d'un serveur Metin2 multi-channel correctement ? Pour la répartition des cores, un schéma de ports et un agencement de démarrage stable, contactez-moi — planifions votre installation ensemble.