Cómo implementar autoupdate incremental del cliente en tu servidor de MU Online

Cada vez que actualizas el cliente de tu servidor de MU Online —un mapa nuevo, un ítem personalizado, una corrección de bug— el jugador necesita descargar ese cambio antes de entrar. Sin un sistema de autoupdate incremental, esto normalmente significa descargar el cliente entero de nuevo, lo que aleja a jugadores con internet más lento y genera picos de tráfico en tu servidor de archivos. Un autoupdate incremental resuelve esto comparando lo que el jugador ya tiene con lo que cambió, descargando solo la diferencia. Este tutorial cubre la arquitectura completa: generación de manifiesto, verificación de integridad, descarga selectiva y manejo de fallos.

Cómo funciona el autoupdate incremental

El principio es simple: el servidor mantiene un manifiesto — una lista de todos los archivos del cliente con su hash y tamaño actuales. El launcher, al abrirse, descarga ese manifiesto y lo compara con un manifiesto local (generado a partir de los archivos que el jugador ya tiene instalados). Cualquier archivo cuyo hash sea diferente (o que no exista localmente) entra en la cola de descarga. Los archivos idénticos se ignoran. El resultado práctico: una actualización de 50 MB en un cliente de 3 GB descarga solo los 50 MB, no los 3 GB enteros.

Prerrequisitos

• Un launcher ya funcional para tu servidor (personalizado o basado en algún framework de launcher de MU).
• Acceso a un servidor de archivos (CDN, VPS o storage) para alojar el manifiesto y los parches.
• Script o herramienta para generar el hash de todos los archivos del cliente (puede hacerse en PHP, Python o C#).
• Entorno de pruebas separado del cliente de producción, para validar el flujo sin afectar a jugadores reales.

Estructura del manifiesto

El manifiesto es normalmente un archivo JSON alojado junto con los parches, listando cada archivo relevante del cliente:

{
  "version": "1.42.0",
  "generated_at": "2026-07-20T14:00:00Z",
  "files": [
    { "path": "Data/Item/Item1.bmd", "sha256": "a1b2c3...", "size": 184320 },
    { "path": "Data/Map/World1.map", "sha256": "d4e5f6...", "size": 942112 },
    { "path": "Main.exe", "sha256": "9f8e7d...", "size": 15728640 }
  ]
}

Generar este manifiesto debe ser un paso automatizado siempre que publiques una actualización — nunca manual, porque un solo hash equivocado invalida la actualización entera para todos los jugadores.

Generando el manifiesto en el servidor (ejemplo en script)

#!/bin/bash
# generate_manifest.sh - recorre la carpeta del cliente y genera manifest.json
OUTPUT="manifest.json"
echo '{"version":"'$1'","generated_at":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","files":[' > $OUTPUT
find ./client -type f | while read -r file; do
  hash=$(sha256sum "$file" | awk '{print $1}')
  size=$(stat -c%s "$file")
  relpath=$(echo "$file" | sed 's|^./client/||')
  echo '{"path":"'$relpath'","sha256":"'$hash'","size":'$size'},' >> $OUTPUT
done
sed -i '$ s/,$//' $OUTPUT
echo ']}' >> $OUTPUT

Ejecuta este script como parte de tu pipeline de publicación, generando siempre un manifiesto nuevo antes de subir los parches al servidor de archivos.

Lógica del launcher (comparación de hash)

El launcher necesita, al abrirse:

1. Descargar el manifest.json remoto.
2. Calcular (o leer de una caché local) el hash de cada archivo ya instalado.
3. Comparar ambas listas y armar la cola de archivos divergentes o ausentes.
4. Descargar solo los archivos de la cola, preferiblemente en paralelo (2-4 conexiones simultáneas).
5. Validar el hash de cada archivo descargado antes de sobrescribir el original.

Diff binario para archivos grandes

Para archivos como el ejecutable principal o paquetes grandes de mapas, incluso un pequeño cambio fuerza la redescarga del archivo entero en el modelo básico. Una optimización adicional es usar diff binario (herramientas como bsdiff/bspatch): el servidor genera un parche pequeño que contiene solo la diferencia binaria entre la versión antigua y la nueva, y el launcher aplica ese parche localmente en lugar de descargar el archivo completo. Esto es más complejo de implementar, pero vale la pena para archivos grandes que cambian con frecuencia moderada.

CDN y distribución

Alojar el manifiesto y los parches en una CDN (en lugar de solo en el VPS del servidor de juego) reduce la carga en el servidor principal durante picos de actualización (por ejemplo, justo después del anuncio de una nueva season). Configura el cache-control apropiado en el manifiesto (corto, para reflejar cambios rápido) y en los archivos de parche (largo, ya que un archivo con hash fijo nunca cambia de contenido).

Manejo de fallos de descarga

Las conexiones inestables son comunes entre jugadores de MU Online en Latinoamérica. El launcher debe:

• Reintentar automáticamente (2-3 intentos) un archivo que falló, antes de marcar la actualización como fallida.
• Permitir reanudar desde donde se quedó (descarga parcial) en lugar de reiniciar el archivo desde cero, especialmente para archivos grandes.
• Nunca aplicar un archivo descargado parcialmente — la validación de hash posdescarga es la protección final contra esto.
• Mostrar un mensaje claro al jugador (nombre del archivo, progreso, error específico) en lugar de un "error genérico de actualización".

Versionado y rollback

Mantén los últimos 2-3 manifiestos anteriores accesibles en el servidor de archivos. Si una actualización causa un problema grave (crash generalizado, ítem roto), necesitas poder revertir el manifiesto activo a la versión anterior rápidamente, sin depender de reconstruir los parches desde cero.

Pruebas antes de publicar

Prueba siempre la actualización en al menos tres escenarios antes de liberarla para todos: (1) cliente limpio, sin ninguna instalación previa; (2) cliente en la versión inmediatamente anterior; (3) cliente en una versión muy antigua (varias actualizaciones atrás), para garantizar que el incremental cubra saltos mayores de versión, no solo el parche más reciente.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Script de generación de manifiesto automatizado en el pipeline de publicación.
• Launcher comparando hash local vs. remoto correctamente.
• Descarga en carpeta temporal con validación posdescarga.
• Soporte para reanudar descarga en archivos grandes.
• CDN configurada para manifiesto y parches.
• Rollback de manifiesto probado y documentado.
• Pruebas en cliente limpio, versión anterior y versión antigua realizadas.

Con el autoupdate incremental funcionando, publicar nuevas actualizaciones deja de ser un evento arriesgado y se convierte en parte natural del ciclo de mantenimiento del servidor — para revisar cómo este cliente se conecta con la infraestructura general del proyecto, consulta la guía de cómo crear un servidor de MU Online.

Preguntas frecuentes