Cómo configurar múltiples GameServers (multicanal) en MU Online

Cuando tu servidor de MU Online empieza a llenarse, un único GameServer deja de dar abasto: lag en eventos, cola para entrar y trabas en spots concurridos. La solución clásica es correr varios GameServers — los "canales" o subservidores que el jugador elige en la lista de servidores. Bien configurado, el multicanal distribuye la carga, crea espacios dedicados (un canal PVP, un canal de eventos) y escala junto con tu base. Mal configurado, genera personajes duplicados, enrutamiento roto y canales que nadie consigue acceder. Este tutorial cubre la arquitectura, los puertos, el registro en el ConnectServer y en el JoinServer, la base de datos compartida y el balanceo — con las variaciones más comunes entre emuladores.

Qué es un servidor multicanal

En la arquitectura del MU, el cliente nunca habla directo con el GameServer en el primer contacto. El flujo es: el cliente conecta al ConnectServer, recibe la lista de servidores (los canales), elige uno, y solo entonces es enrutado al GameServer de ese canal. Por detrás, el JoinServer se encarga del login/cuentas y la base de datos guarda personajes e ítems. Un servidor "multicanal" es simplemente varios procesos de GameServer corriendo al mismo tiempo, cada uno con su puerto y su código, todos registrados en el ConnectServer y compartiendo la misma base de datos. Para el jugador, cada GameServer es un "Canal 1", "Canal 2", "PVP" — y como la base de datos es la misma, el personaje es idéntico en cualquiera de ellos.

Por qué tener varios GameServers

• Distribuir carga: dividir 1000 jugadores en 3 canales de ~330 alivia la CPU, la memoria y la red de cada instancia.
• Reducir el lag en spots y eventos: menos gente por canal significa menos concurrencia por mob y menos paquetes por segundo.
• Canales temáticos: un canal marcado como "PVP" o "Eventos" separa públicos sin necesidad de otro servidor.
• Mantenimiento sin tumbar todo: puedes reiniciar un canal para aplicar un ajuste mientras los otros siguen en el aire.
• Escala horizontal: cuando un VPS se satura, mueves un canal a otra máquina apuntando a la misma base de datos.

Prerrequisitos

• Un servidor de MU ya corriendo con un GameServer, ConnectServer y JoinServer funcionales (mira el tutorial de creación de servidor).
• Acceso a los archivos de configuración de GameServer, ConnectServer y JoinServer.
• La base de datos (MSSQL en la mayoría de los emuladores) accesible por todas las instancias.
• Puertos libres en el firewall/router para cada canal.
• Backup completo de los archivos de config y de la base de datos antes de cualquier cambio.

Archivos y componentes involucrados

Los nombres varían según el emulador (IGCN, MuEMU, X-Team, Season 6). Los más comunes:

> Trata cada archivo como crítico: un ServerCode o puerto duplicados tumban el boot del canal afectado. Siempre edita copias y prueba un canal a la vez.

Paso 1 — Planea puertos y ServerCodes

Antes de copiar nada, define en el papel la identidad de cada canal. Cada GameServer necesita tres cosas únicas: un ServerCode (número), un puerto de GameServer y un nombre exhibido en la lista. Un plan típico para tres canales:

El ConnectServer suele escuchar en el puerto 44405 y el JoinServer en el 55970 (estos son ejemplos — varían según el emulador). Lo importante es que los puertos de GameServer no colisionen entre sí y que cada uno esté liberado en el firewall.

Paso 2 — Duplica la carpeta/config del GameServer

Cada canal es un proceso propio. Copia la carpeta del GameServer (o el conjunto de archivos de config) una vez por canal — por ejemplo GameServer_C1, GameServer_C2, GameServer_C3. Manteniendo carpetas separadas evitas que dos canales peleen por logs, dumps y archivos temporales, y consigues reiniciar uno sin afectar a los otros.

Paso 3 — Configura puerto, código y nombre de cada GameServer

Abre el archivo de configuración de cada GameServer y ajusta los valores que necesitan ser únicos. En muchos emuladores el bloque es parecido a esto:

[GameServerInfo]
ServerName   = "Canal 1"
ServerCode   = 0
GameServerPort = 55901
; direcciones de los servicios que este canal consume
JoinServerAddress = 127.0.0.1
JoinServerPort    = 55970
ConnectServerAddress = 127.0.0.1
ConnectServerPort    = 44405
; límite de jugadores de este canal (balanceo)
MaxUserCount = 400

Repite para el Canal 2 (ServerCode = 1, GameServerPort = 55902, ServerName = "Canal 2") y para el Canal 3 (ServerCode = 2, GameServerPort = 55903, ServerName = "PVP"). Lo que cambia por canal: ServerName, ServerCode, GameServerPort y opcionalmente MaxUserCount. Lo que permanece igual: las direcciones del JoinServer, del ConnectServer y la conexión de base de datos.

Paso 4 — Registra los canales en el ConnectServer

El ConnectServer es quien arma la lista que el jugador ve. Para cada GameServer, agrega una entrada apuntando ServerCode → IP:puerto. El formato típico:

; ServerCode  Nombre      IP           Puerto
0            "Canal 1"    127.0.0.1    55901
1            "Canal 2"    127.0.0.1    55902
2            "PVP"        200.100.50.10 55903

Nota que la IP puede ser diferente por canal: si el Canal 3 corre en otro VPS, usa la IP pública de esa máquina. Si todos están en la misma máquina, usa la IP local/loopback. El ServerCode aquí tiene que coincidir con el ServerCode configurado en el GameServer correspondiente — es esa correspondencia la que hace funcionar el enrutamiento.

Paso 5 — Apunta el JoinServer y comparte la base de datos

El JoinServer valida la cuenta y encamina al jugador. En general tienes un único JoinServer para todos los canales — confirma que conoce todos los ServerCodes y que su conexión de base de datos apunta a la misma base que usan los GameServers. Este es el punto más importante del multicanal: todos los GameServers y el JoinServer usan la misma base (ej.: MuOnline + Me_MuOnline vía ODBC). Así, el personaje creado en el Canal 1 ya existe en el Canal 2, con el mismo inventario y Zen. Bases separadas = mundos separados (no es el objetivo aquí).

Paso 6 — Libera los puertos en el firewall

Cada puerto de GameServer necesita estar accesible desde afuera. En Windows, libera los puertos TCP en el firewall; en el VPS/router, haz el reenvío (port forward) de cada uno:

; TCP a liberar (ejemplo)
44405   ; ConnectServer
55970   ; JoinServer
55901   ; GameServer Canal 1
55902   ; GameServer Canal 2
55903   ; GameServer PVP

Olvidarse de liberar el puerto de un canal es la causa n.º 1 de "el canal aparece en la lista pero da error al entrar". El canal sube localmente, pero el cliente no alcanza el puerto.

Paso 7 — Levanta los servicios en el orden correcto

El orden de inicialización importa. Levanta: 1) base de datos, 2) JoinServer, 3) ConnectServer, 4) cada GameServer (Canal 1, después 2, después 3). Levantar un GameServer antes del JoinServer/base de datos suele generar error de conexión y el canal no se registra. Al levantar cada GameServer, acompaña la consola: debe reportar "conectado al JoinServer" y "registrado en el ConnectServer".

Paso 8 — Prueba el enrutamiento en juego

1. Abre el cliente y confirma que todos los canales aparecen en la lista de servidores.
2. Entra en el Canal 1 con una cuenta de prueba, crea/mueve un personaje, dropea un ítem.
3. Sal y entra en el Canal 2 con la misma cuenta — el personaje y el ítem deben estar allí (prueba de la base de datos compartida).
4. Verifica el medidor de ocupación de cada canal en la lista.
5. Fuerza un canal (ej.: reinicia el Canal 3) y confirma que los otros siguen en el aire.

Cuidados de balanceo

Tener canales no basta — es necesario distribuir gente de forma saludable:

• Define MaxUserCount por canal de acuerdo con la capacidad de la máquina, no con el ego. Es mejor 3 canales de 350 estables que 3 de 800 trabando.
• Monitorea CPU/RAM por proceso. Cada GameServer es un proceso; si uno se satura antes que los otros, reduce su límite o muévelo de máquina.
• No dejes que un canal se vuelva "el único". Si todos entran en el Canal 1, considera spawns de evento rotativos entre canales para esparcir la población.
• Cuidado con los eventos globales. Un boss/evento que corre en todos los canales multiplica la carga simultáneamente — escalona horarios si es necesario.
• La base de datos es el cuello de botella compartido. Muchos canales golpeando el mismo MSSQL exigen una base bien dimensionada; monitorea el tiempo de respuesta de las queries.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Plan de puertos y ServerCodes definido (todos únicos).
• Config de cada GameServer con nombre, código y puerto propios.
• Todos los canales registrados en el ConnectServer (ServerCode ↔ IP:puerto coincidiendo).
• JoinServer conociendo todos los canales y en la misma base de datos.
• Base de datos compartida confirmada (el personaje persiste entre canales).
• Puertos liberados en el firewall/router (ConnectServer, JoinServer y cada GameServer).
• Servicios iniciados en el orden correcto y consolas sin error.
• MaxUserCount definido por canal conforme a la capacidad de la máquina.
• Prueba in-game de enrutamiento y persistencia entre canales concluida.
• Backup de los archivos de config y de la base de datos guardado antes del público.

Con el multicanal en el aire, tienes una base que escala junto con la comunidad: para agregar el "Canal 4", basta con repetir los pasos con un nuevo ServerCode, un nuevo puerto y una nueva entrada en el ConnectServer. Documenta el par ServerCode:puerto de cada canal en una planilla — esto evita colisiones y hace trivial mover un canal a otra máquina cuando la población crezca.

Preguntas frecuentes