How to configure multiple GameServers (multi-channel) in MU Online

When your MU Online server starts to fill up, a single GameServer can no longer keep up: lag during events, queues to get in and freezes in crowded spots. The classic solution is to run multiple GameServers — the "channels" or sub-servers the player picks from the server list. Well configured, multi-channel distributes the load, creates dedicated spaces (a PVP channel, an events channel) and scales along with your base. Poorly configured, it generates duplicate characters, broken routing and channels no one can access. This tutorial covers the architecture, the ports, the registration in the ConnectServer and the JoinServer, the shared database and the balancing — with the most common variations across emulators.

What a multi-channel server is

In the MU architecture, the client never talks directly to the GameServer on first contact. The flow is: the client connects to the ConnectServer, receives the server list (the channels), picks one, and only then is routed to the GameServer of that channel. Behind the scenes, the JoinServer handles login/accounts and the database stores characters and items. A "multi-channel" server is simply multiple GameServer processes running at the same time, each with its own port and code, all registered in the ConnectServer and sharing the same database. To the player, each GameServer is a "Channel 1", "Channel 2", "PVP" — and since the database is the same, the character is identical on any of them.

Why have multiple GameServers

• Distribute load: splitting 1000 players into 3 channels of ~330 relieves CPU, memory and the network of each instance.
• Reduce lag in spots and events: fewer people per channel means less competition for mobs and fewer packets per second.
• Themed channels: a channel marked as "PVP" or "Events" separates audiences without needing another server.
• Maintenance without taking everything down: you can restart one channel to apply a tweak while the others stay up.
• Horizontal scaling: when a VPS saturates, you move a channel to another machine pointing to the same database.

Prerequisites

• A MU server already running with a functional GameServer, ConnectServer and JoinServer (see the server creation tutorial).
• Access to the configuration files of the GameServer, ConnectServer and JoinServer.
• The database (MSSQL on most emulators) accessible by all instances.
• Free ports in the firewall/router for each channel.
• A complete backup of the config files and the database before any change.

Files and components involved

The names vary by emulator (IGCN, MuEMU, X-Team, Season 6). The most common ones:

> Treat each file as critical: a duplicated ServerCode or port takes down the boot of the affected channel. Always edit copies and test one channel at a time.

Step 1 — Plan ports and ServerCodes

Before copying anything, define each channel's identity on paper. Each GameServer needs three unique things: a ServerCode (number), a GameServer port and a name shown in the list. A typical plan for three channels:

The ConnectServer usually listens on port 44405 and the JoinServer on 55970 (these are examples — they vary by emulator). What matters is that the GameServer ports do not collide with each other and that each one is open in the firewall.

Step 2 — Duplicate the GameServer folder/config

Each channel is its own process. Copy the GameServer folder (or the set of config files) once per channel — for example GameServer_C1, GameServer_C2, GameServer_C3. Keeping separate folders prevents two channels from fighting over logs, dumps and temporary files, and lets you restart one without affecting the others.

Step 3 — Configure each GameServer's port, code and name

Open the configuration file of each GameServer and adjust the values that need to be unique. In many emulators the block looks like this:

[GameServerInfo]
ServerName   = "Channel 1"
ServerCode   = 0
GameServerPort = 55901
; addresses of the services this channel consumes
JoinServerAddress = 127.0.0.1
JoinServerPort    = 55970
ConnectServerAddress = 127.0.0.1
ConnectServerPort    = 44405
; player limit for this channel (balancing)
MaxUserCount = 400

Repeat for Channel 2 (ServerCode = 1, GameServerPort = 55902, ServerName = "Channel 2") and for Channel 3 (ServerCode = 2, GameServerPort = 55903, ServerName = "PVP"). What changes per channel: ServerName, ServerCode, GameServerPort and optionally MaxUserCount. What stays the same: the JoinServer and ConnectServer addresses and the database connection.

Step 4 — Register the channels in the ConnectServer

The ConnectServer is what builds the list the player sees. For each GameServer, add an entry pointing ServerCode → IP:port. The typical format:

; ServerCode  Name        IP           Port
0            "Channel 1"  127.0.0.1    55901
1            "Channel 2"  127.0.0.1    55902
2            "PVP"        200.100.50.10 55903

Note that the IP can differ per channel: if Channel 3 runs on another VPS, use the public IP of that machine. If they are all on the same machine, use the local/loopback IP. The ServerCode here has to match the ServerCode configured on the corresponding GameServer — it is this correspondence that makes routing work.

Step 5 — Point the JoinServer and share the database

The JoinServer validates the account and forwards the player. In general you have a single JoinServer for all channels — confirm that it knows all the ServerCodes and that its database connection points to the same database the GameServers use. This is the most important point of multi-channel: all GameServers and the JoinServer use the same database (e.g. MuOnline + Me_MuOnline via ODBC). That way, the character created on Channel 1 already exists on Channel 2, with the same inventory and Zen. Separate databases = separate worlds (not the goal here).

Step 6 — Open the ports in the firewall

Each GameServer port needs to be accessible from the outside. On Windows, open the TCP ports in the firewall; on the VPS/router, do the forwarding (port forward) of each one:

; TCP to open (example)
44405   ; ConnectServer
55970   ; JoinServer
55901   ; GameServer Channel 1
55902   ; GameServer Channel 2
55903   ; GameServer PVP

Forgetting to open a channel's port is the No. 1 cause of "the channel shows up in the list but errors out on entry". The channel boots locally, but the client cannot reach the port.

Step 7 — Start the services in the correct order

The startup order matters. Start: 1) the database, 2) the JoinServer, 3) the ConnectServer, 4) each GameServer (Channel 1, then 2, then 3). Starting a GameServer before the JoinServer/database usually generates a connection error and the channel does not register. As you start each GameServer, watch the console: it should report "connected to the JoinServer" and "registered in the ConnectServer".

Step 8 — Test the routing in-game

1. Open the client and confirm that all channels appear in the server list.
2. Enter Channel 1 with a test account, create/move a character, drop an item.
3. Leave and enter Channel 2 with the same account — the character and the item should be there (proof of the shared database).
4. Check the occupancy meter of each channel in the list.
5. Force a channel (e.g. restart Channel 3) and confirm that the others stay up.

Balancing considerations

Having channels is not enough — you need to distribute people in a healthy way:

• Set MaxUserCount per channel according to the machine's capacity, not the ego. Better 3 stable channels of 350 than 3 of 800 freezing up.
• Monitor CPU/RAM per process. Each GameServer is a process; if one saturates before the others, reduce its limit or move it to another machine.
• Do not let one channel become "the only one". If everyone enters Channel 1, consider rotating event spawns across channels to spread the population.
• Watch out for global events. A boss/event that runs on all channels multiplies the load simultaneously — stagger the schedules if necessary.
• The database is the shared bottleneck. Many channels hitting the same MSSQL require a well-sized database; monitor the query response time.

Common errors and fixes

Launch checklist

• Ports and ServerCodes plan defined (all unique).
• Config of each GameServer with its own name, code and port.
• All channels registered in the ConnectServer (ServerCode ↔ IP:port matching).
• JoinServer knowing all channels and on the same database.
• Shared database confirmed (character persists between channels).
• Ports opened in the firewall/router (ConnectServer, JoinServer and each GameServer).
• Services started in the correct order and consoles without errors.
• MaxUserCount set per channel according to the machine's capacity.
• In-game test of routing and persistence between channels completed.
• Backup of the config files and the database saved before going public.

With multi-channel up, you have a base that scales along with the community: to add "Channel 4", just repeat the steps with a new ServerCode, a new port and a new entry in the ConnectServer. Document the ServerCode:port pair of each channel in a spreadsheet — it prevents collisions and makes it trivial to move a channel to another machine when the population grows.

Frequently asked questions