Metin2 channel structure: core distribution and ports

When you set up a Metin2 server for the first time, the most confusing topic is the Metin2 channel structure: the "Channel 1, Channel 2, Channel 3" list the player sees is actually served by how many background processes, which map runs on which core, and how are the ports distributed? In this article I explain the difference between a channel and a core, the role of the auth and db servers, and the port layout of a classic multi-channel server with practical examples.

The difference between a channel and a core

Many people think a "channel" and a "core" are the same thing, but they are different layers. A channel is a logical division the player sees on the selection screen: think of it as multiple copies of the same world used to spread the load. Every channel contains all of the maps (villages, hunting grounds, dungeons).

A core inside a channel, however, is a separate process that runs a subset of the maps. A single game process does not carry every map; the maps are shared out among the cores. For example, if a channel has four cores, the starting villages might run on core1, the mid-level hunting grounds on core2, and the high-level maps and dungeons on core3 and core4. When a player moves between maps a handover happens between cores, but the player never notices it.

The role of the auth and db servers

A multi-channel setup has two central pieces:

• auth: the server that validates account logins. The client connects here first, the username/password is checked and a session token is produced. The auth is usually a dedicated game process running on its own port with its own CONFIG file.
• db: the database cache server that all cores connect to in common. Data such as characters, inventory and guilds lives in MySQL, but the cores do not talk to it directly — they go through the db process. This keeps data in sync, so a player's character stays consistent when moving from one core to another.

So the connection chain looks like this: client → auth (login) → the core of the chosen channel → and all cores in the background → db → MySQL. There is only ever one auth and one db server; the cores are the replicated part.

Port logic and CONFIG

Every core is started with a CONFIG file in its own folder, which defines the port it listens on, which channel it belongs to, and the P2P port it uses for inter-core communication. A consistent port scheme makes life much easier. A common convention is:

• Channel 1 cores: 13001, 13002, 13003, 13004
• Channel 2 cores: 13011, 13012, 13013, 13014
• Channel 3 cores: 13021, 13022, 13023, 13024
• auth: a separate port such as 11002 — db: a separate port such as 15000

What matters is that the scheme does not collide and stays logical; the numbers themselves are arbitrary. A typical core CONFIG file roughly looks like this:

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

Here PORT is the game port players connect to, while P2P_PORT is used to talk to the other cores in the same channel. DB_ADDR and DB_PORT tell the core how to reach the db process. The auth process's CONFIG additionally carries a setting marking it as an authentication server and is usually run with a special channel number (for example 99).

Distributing maps across cores

Which maps a core loads is determined by the server-side map list. Each core only loads the map folders assigned to it; unassigned maps are considered "remote" for that core. When a player walks onto a map that is not on a given core, they are transferred over the P2P link to the core that hosts that map. When you plan the distribution, watch two things:

• Load balance: do not pile the busiest hunting grounds onto a single core; spread player density across the cores.
• Consistency: never assign the same map to two different cores. Each map must run on exactly one core, otherwise the handover breaks.

In practice the starting villages and the constantly crowded main squares are usually given their own core, so that a crowd in one hunting ground does not affect city performance.

Startup order and process management

The startup order of the server processes matters, because cores try to connect to db as they boot. The correct order is:

1. The MySQL service (database) must be running.
2. The db process is started.
3. The auth process is started.
4. The cores of the channels are started one by one.

Because following the processes by hand is tiring, most admins use a simple startup script. An example control-script approach:

#!/bin/sh
# each core is started from its own folder
for dir in db auth ch1_core1 ch1_core2 ch1_core3 ch1_core4; do
    cd "/usr/metin2/$dir" && ./game &
done

When a core crashes it usually leaves a core dump (a core file); you can inspect it with gdb to see which function it blew up in. That is why running the cores under screen or a service manager and keeping the logs separate is a lifesaver when something goes wrong.

How many cores do you need?

There is no fixed answer; it depends on the player count and the hardware. Because each game process runs largely single-threaded, increasing the number of cores on a multi-core server lets you use the CPU better. A general starting point: for a small server 2 cores per channel is enough, while a crowded server benefits from 4 cores per channel and more than one channel. Start with 1 channel + 2 cores, then add channels and cores as the player base grows.

Frequently Asked Questions

Can I increase the number of channels later?

Yes. Adding a new channel comes down to creating CONFIG files for that channel's cores, assigning non-colliding ports, and updating the server list the client sees. Because the database stays shared, characters are identical across all channels.

Can players choose which channel they are on?

Yes, after logging in the player picks from the channel list. Since channels share the same world, characters and items do not change; only which copy of the server you are currently playing on changes. This is the main way to spread the load during peak hours.

Can I merge auth and db into a single process?

Architecturally it is correct, and recommended, to keep them separate. db is the shared data layer for all cores while auth only handles login; keeping the two apart gives you a far more manageable structure for both security and debugging.

Want to build the architecture of a multi-channel Metin2 server the right way? For core distribution, a port scheme and a stable startup layout, get in touch with me — let's plan your setup together.