Consigna y alcance

Enunciado del trabajo

Universidad Austral

Sistemas Distribuidos · Trabajo práctico final

Agustín Martínez, Alan Fierro, Nicolás Mangini y Tomás Alcázar

01 · Contexto

MMO medieval, persistente y distribuido

Jugadores entran a instancias pagando oro, combaten contra un jefe y reciben las recompensas que correspondan por victoria o derrota. Los ítems pueden venderse en un mercado global; el oro también se compra con dinero real.

02 · Infraestructura

3 datacenters

Brasil, Estados Unidos y Zúrich. El cliente y los centros se comunican por gRPC. Un combate global tiene una instancia lógica con líder y réplicas; los nodos recuperados se sincronizan antes de reincorporarse.

03 · Datos y negocio

Estado y restricciones

Datos personales y bancarios: solo en el datacenter hogar. Cambios de oro y objetos: conservar 90 días. Durante saturación se priorizan sesiones existentes.

04 · Fallas a cubrir

Cliente e infraestructura

Desconexión, latencia, caída de módulos o datacenters y particiones de red. Seguridad queda fuera de esta versión por la actualización del docente.

Enunciado original

Consultá la consigna completa del trabajo.

P · Problema

Requisito

F · Fallas

G · Garantías

Requisito

S · Solución

Propuesta

Leer desarrollo

S · Soluciones

Propuestas

Trade-offs

Límites y costos

Trade-off

Límites y costos

Interacción de módulos

6 pasos
Cliente móvilInstanciasLogs replicadosCombateRecompensasOro / inventario01Enviar golpe02Publicar golpe03Consumir en orden04Registrar resultado05Procesar premios06Acreditar por clave
Elegí una flecha o avanzá por pasos.
Términos de este caso

Seleccioná un módulo para ver qué hace, qué estado administra y con quién interactúa. El esquema es lógico: no representa servidores individuales.

Mapa de módulos

AccesoJuegoEconomíaSoporte
ASTERIA ONLINEMódulos lógicos · responsabilidades e interacciones01 ACCESO Y DESCUBRIMIENTO02 EJECUCIÓN DEL JUEGO03 ECONOMÍA DEL JUEGO04 PERSISTENCIA Y RECUPERACIÓNCliente móvil → Acceso y sesiones: gRPCAcceso y sesiones → Directorio de zonas: consultaDirectorio de zonas → Gestor de ingreso: selecciónGestor de ingreso → Gestor de instancias: ingresoGestor de instancias → Procesador de combate: accionesProcesador de combate → Servicio de recompensas: resultadoServicio de recompensas → Oro e inventario: acreditarAcceso y sesiones → Mercado: ventaAcceso y sesiones → Pagos reales: pagoMercado → Oro e inventario: transferenciaPagos reales → Oro e inventario: acreditaciónGestor de ingreso → Oro e inventario: oro de entradaGestor de instancias → Directorio de zonas: ocupaciónGestor de ingreso → WAL y pertenencia: WAL y registroProcesador de combate → Logs replicados: golpes y tiempoMercado → Logs replicados: comprasDirectorio de zonas → Logs replicados: cambiosServicio de recompensas → Logs replicados: offsetOro e inventario → Registro de auditoría: registro 90 dRecuperación → Gestor de instancias: reubicaciónRecuperación → Acceso y sesiones: sesionesCliente móvilAcciones y reintentosAcceso / sesionesAdmisión y reconexiónDirectorioListado local de zonasIngresoCobro y pertenenciaInstanciasCreación, cupo, ubicaciónCombateGolpes, tiempo y resultadoRecompensasEntrega idempotenteMercadoCompra y venta de ítemsPagos realesCompra de oro y OutboxOro / inventarioSaldos y propiedadRecuperaciónReubicar ejecución y sesionesWAL / registroSolicitudes y jugador-instanciaLogs replicadosOrden, offset y recuperaciónAuditoría 90 díasCambios de oro y objetosLas líneas de soporte son dependencias lógicas. La coordinación concreta se detalla por proceso.
Rueda para zoom · arrastrá para mover
Responsabilidad

Gestor de ingreso

Coordina validación de cupo, cobro de entrada y registro único del jugador; resuelve reintentos por requestId.

Estado administrado
Solicitud y resultado en WAL; vinculación jugador-instancia por quórum.
Interactúa con

Líneas continuas: interacción entre funciones. Líneas punteadas: persistencia o recuperación. Los almacenamientos son responsabilidades lógicas y pueden implementarse mediante componentes replicados.

El estado personal y bancario permanece en el hogar; las instancias y el estado del juego pueden operar entre datacenters según su función.

Instancia normal

Una mazmorra se ejecuta en un datacenter. Por defecto nace en el hogar de quien la crea y puede ser reubicada si ese datacenter falla.

BRASILInstancia localDatos personales + pagospermanecen aquíESTADOS UNIDOSServicios localesDatos personales + pagospermanecen aquíZÚRICHServicios localesDatos personales + pagospermanecen aquígRPC entre datacenters · directorio replicado
Directorio · Cada centro consulta su réplica local.
Pertenencia · El registro único sigue necesitando mayoría.
Datos bancarios · No se trasladan con la instancia.
Ubicación del estado
EstadoUbicación / políticaMecanismo
Datos personales y bancariosSolo en el datacenter hogar.Base local replicada entre nodos.
Pagos y OutboxDatacenter hogar del jugador.Pago y Outbox juntos; oro e identificador en una transacción; conciliación con el proveedor tras recuperación.
Pertenencia jugador-instanciaEstado coordinado en los tres datacenters.WAL confirmado por mayoría 2/3; pertenencia exclusiva, sin replicar todos los datos del jugador.
Eventos de combate y mercadoParticionados por instancia o por ítem.Consumidor único por partición; mayoría para confirmar; sincronización antes de reincorporar nodos.
Directorio de zonasUna copia local por datacenter.Actualización asíncrona desde logs.
Oro e inventarioEstado de juego; puede moverse entre datacenters.Transacciones atómicas de ingreso y venta; identificadores únicos para evitar duplicaciones.
Cambios económicos (90 días)Requerimiento de negocio, sin ubicación definida.Auditoría aún no detallada.
Asteria Online · TP final