Metin2 Channel-Struktur: Core-Verteilung und Ports

Wenn du zum ersten Mal einen Metin2-Server aufsetzt, ist das verwirrendste Thema die Metin2 Channel-Struktur: Die Liste „Channel 1, Channel 2, Channel 3“, die der Spieler sieht, wird im Hintergrund eigentlich von wie vielen Prozessen bedient, welche Map läuft auf welchem Core und wie werden die Ports verteilt? In diesem Artikel erkläre ich den Unterschied zwischen einem Channel und einem Core, die Rolle der auth- und db-Server sowie das Port-Layout eines klassischen Multi-Channel-Servers anhand praktischer Beispiele.

Der Unterschied zwischen Channel und Core

Viele halten „Channel“ und „Core“ für dasselbe, doch es sind unterschiedliche Ebenen. Ein Channel ist eine logische Aufteilung, die der Spieler im Auswahlbildschirm sieht: Stell dir mehrere Kopien derselben Welt vor, um die Last zu verteilen. Jeder Channel enthält alle Maps (Dörfer, Jagdgebiete, Dungeons).

Ein Core innerhalb eines Channels ist hingegen ein eigener Prozess, der nur eine Teilmenge der Maps betreibt. Ein einzelner game-Prozess trägt nicht jede Map; die Maps werden auf die Cores verteilt. Hat ein Channel zum Beispiel vier Cores, könnten die Startdörfer auf core1 laufen, die mittleren Jagdgebiete auf core2 und die hochstufigen Maps samt Dungeons auf core3 und core4. Wechselt ein Spieler zwischen Maps, findet eine Übergabe zwischen den Cores statt, doch der Spieler bemerkt sie nie.

Die Rolle der auth- und db-Server

Ein Multi-Channel-Setup hat zwei zentrale Bausteine:

• auth: der Server, der die Account-Logins prüft. Der Client verbindet sich zuerst hierher, Benutzername/Passwort werden geprüft und ein Sitzungs-Token wird erzeugt. Der auth ist üblicherweise ein dedizierter game-Prozess, der auf einem eigenen Port mit seiner eigenen CONFIG-Datei läuft.
• db: der Datenbank-Cache-Server, mit dem sich alle Cores gemeinsam verbinden. Daten wie Charaktere, Inventar und Gilden liegen in MySQL, doch die Cores sprechen nicht direkt damit — sie gehen über den db-Prozess. So bleiben die Daten synchron, und der Charakter eines Spielers bleibt konsistent, wenn er von einem Core zum anderen wechselt.

Die Verbindungskette sieht also so aus: Client → auth (Login) → der Core des gewählten Channels → und alle Cores im Hintergrund → db → MySQL. Es gibt immer nur einen auth- und einen db-Server; vervielfacht werden die Cores.

Port-Logik und CONFIG

Jeder Core wird mit einer CONFIG-Datei in seinem eigenen Ordner gestartet, die festlegt, auf welchem Port er lauscht, zu welchem Channel er gehört und welchen P2P-Port er für die Kommunikation zwischen den Cores nutzt. Ein konsistentes Port-Schema erleichtert die Arbeit enorm. Eine gängige Konvention ist:

• Channel-1-Cores: 13001, 13002, 13003, 13004
• Channel-2-Cores: 13011, 13012, 13013, 13014
• Channel-3-Cores: 13021, 13022, 13023, 13024
• auth: ein separater Port wie 11002 — db: ein separater Port wie 15000

Wichtig ist, dass das Schema nicht kollidiert und logisch bleibt; die Zahlen selbst sind frei wählbar. Eine typische CONFIG-Datei eines Cores sieht ungefähr so aus:

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

Hier ist PORT der Spielport, mit dem sich die Spieler verbinden, während P2P_PORT dazu dient, mit den anderen Cores desselben Channels zu sprechen. DB_ADDR und DB_PORT sagen dem Core, wie er den db-Prozess erreicht. Die CONFIG des auth-Prozesses trägt zusätzlich eine Einstellung, die ihn als Authentifizierungsserver kennzeichnet, und wird üblicherweise mit einer speziellen Channel-Nummer (zum Beispiel 99) betrieben.

Maps auf die Cores verteilen

Welche Maps ein Core lädt, wird durch die serverseitige Map-Liste bestimmt. Jeder Core lädt nur die ihm zugewiesenen Map-Ordner; nicht zugewiesene Maps gelten für diesen Core als „entfernt“. Betritt ein Spieler eine Map, die auf einem bestimmten Core nicht vorhanden ist, wird er über die P2P-Verbindung an den Core übergeben, der diese Map betreibt. Bei der Planung der Verteilung achtest du auf zwei Dinge:

• Lastverteilung: häufe nicht die meistbesuchten Jagdgebiete auf einem einzigen Core an; verteile die Spielerdichte über die Cores.
• Konsistenz: weise niemals dieselbe Map zwei verschiedenen Cores zu. Jede Map muss auf genau einem Core laufen, sonst bricht die Übergabe.

In der Praxis erhalten die Startdörfer und die ständig überfüllten Hauptplätze meist einen eigenen Core, damit ein Andrang in einem Jagdgebiet die Stadt-Performance nicht beeinträchtigt.

Startreihenfolge und Prozessverwaltung

Die Startreihenfolge der Serverprozesse ist wichtig, weil die Cores beim Hochfahren versuchen, sich mit db zu verbinden. Die richtige Reihenfolge ist:

1. Der MySQL-Dienst (Datenbank) muss laufen.
2. Der db-Prozess wird gestartet.
3. Der auth-Prozess wird gestartet.
4. Die Cores der Channels werden nacheinander gestartet.

Da es mühsam ist, die Prozesse von Hand zu verfolgen, nutzen die meisten Admins ein einfaches Startskript. Ein beispielhafter Ansatz für ein Kontrollskript:

#!/bin/sh
# jeder Core wird aus seinem eigenen Ordner gestartet
for dir in db auth ch1_core1 ch1_core2 ch1_core3 ch1_core4; do
    cd "/usr/metin2/$dir" && ./game &
done

Wenn ein Core abstürzt, hinterlässt er meist einen Core-Dump (eine core-Datei); du kannst ihn mit gdb untersuchen, um zu sehen, in welcher Funktion er geplatzt ist. Deshalb ist es ein Lebensretter, die Cores unter screen oder einem Service-Manager laufen zu lassen und die Logs getrennt zu halten, wenn etwas schiefgeht.

Wie viele Cores brauchst du?

Es gibt keine feste Antwort; es hängt von der Spielerzahl und der Hardware ab. Da jeder game-Prozess weitgehend single-threaded läuft, kannst du durch mehr Cores auf einem Mehrkern-Server die CPU besser nutzen. Ein allgemeiner Ausgangspunkt: Für einen kleinen Server reichen 2 Cores pro Channel, während ein voller Server von 4 Cores pro Channel und mehr als einem Channel profitiert. Beginne mit 1 Channel + 2 Cores und füge Channels und Cores hinzu, wenn die Spielerbasis wächst.

Häufige Fragen

Kann ich die Anzahl der Channels später erhöhen?

Ja. Einen neuen Channel hinzuzufügen läuft darauf hinaus, CONFIG-Dateien für dessen Cores zu erstellen, kollisionsfreie Ports zu vergeben und die Serverliste zu aktualisieren, die der Client sieht. Da die Datenbank gemeinsam bleibt, sind die Charaktere über alle Channels hinweg identisch.

Können Spieler wählen, auf welchem Channel sie sind?

Ja, nach dem Login wählt der Spieler aus der Channel-Liste. Da die Channels dieselbe Welt teilen, ändern sich Charaktere und Gegenstände nicht; es ändert sich nur, auf welcher Kopie des Servers du gerade spielst. Das ist der Hauptweg, um die Last zu Stoßzeiten zu verteilen.

Kann ich auth und db zu einem einzigen Prozess zusammenfassen?

Architektonisch ist es korrekt und empfohlen, sie getrennt zu halten. db ist die gemeinsame Datenebene für alle Cores, während auth sich nur um den Login kümmert; beide getrennt zu halten ergibt eine weitaus besser handhabbare Struktur für Sicherheit und Debugging.

Möchtest du die Architektur eines Multi-Channel-Metin2-Servers richtig aufbauen? Für Core-Verteilung, ein Port-Schema und ein stabiles Start-Layout nimm Kontakt mit mir auf — lass uns dein Setup gemeinsam planen.