Haciendo Tu Server Persistente

[gdl]

 
Hola, hola...

Para llenar esos ratos de aburrimiento ;) estoy haciendo un servidor y su cliente correspondiente para un MMOG. Ahora estoy más centrado en el servidor. Como fácilmente se comprende, si quiero tener un mundo virtual con más de cien usuarios necesito dos cosas (como mínimo porque en verdad son muchíiiiiisimas más)

- Persistencia (Que no se vaya todo al garete cuando el servidor caiga... porque caerá alguna que otra vez o se apagará para mantenimiento)

- Eficiencia (Para poder alejar lo máximo posible el punto de sobrecarga del sistema y permitir tantos usuarios como sea posible)

Estas dos cosas están en cierta forma relacionadas ya que hacer las cosas persistentes implica grabarlas a disco tarde o temprano y el disco es mucho más lento que la memoria.

Aunque tuviera un montón hebras dedicadas a la persistencia, es muy improbable que pudieran seguir el ritmo de cambio del estado del mundo (y mientras creáis que sí, multiplicad por 10 el número de usuarios, enemigos, objetos y demás que hay que mantener actualizado). El disco es un cuello de botella en este caso. Existen muchos métodos para paliar estos problemillas, pero no quisiera tener que ponerme a programarlos si no es estrictamente necesario porque son muy tediosos.

Por otra parte, los sistemas gestores de bases de datos llevan años trabajando en este asunto y parece que lo tienen más o menos solucionado. El problema es que usan unos interfaces muy estrictos con tipos muy definidos (nada de guardar objetos enteros en la BD y mucho menos si tienen punteros o referencias, aunque esto es otro cuento). Habría que 1) serializarlos y guardarlos como datos o 2) grabar sus atributos uno a uno en campos de la BD. Sea como fuere, habría que acceder a la base de datos mediante un socket, una fifo, un stream o similar y eso lleva implícita otra serialización: las de las instrucciones.  (nooo)

Así que mi duda es

¿Creéis vosotros que merece la pena usar una BD (con todo el follón adicional) para llevar el estado de un mundo virtual o es mejor tenerlo en memoria (en forma de objetos C++, variables, etc.) y que el server se encargue de serializarlo (con todo el follón adicional)?

Es decir

¿Qué es más pesado de hacer? ¿El acceso a la base de datos con todos esos bonitos SELECTs y demás o hacerte un mini-gestor de bases de datos para mantener la persistencia de tu mundo virtual?

Gracias por anticipado,

 gdl

PD: Ya sé que la cosa  es un poco ambigua sin dar más datos, por centraros un poco tomad como referencia un servidor de Ultima Online, Tibia, etc.

PPD: También hay que tener en cuenta si se va a usar un script, carga dinámica de objetos, modificación en caliente de los datos, etc. pero ya no tenía ganas de escribir más.

[Zaelsius]

Como fácilmente se comprende, si quiero tener un mundo virtual con más de cien usuarios necesito dos cosas (como mínimo porque en verdad son muchíiiiiisimas más)

- Persistencia (Que no se vaya todo al garete cuando el servidor caiga... porque caerá alguna que otra vez o se apagará para mantenimiento)

- Eficiencia (Para poder alejar lo máximo posible el punto de sobrecarga del sistema y permitir tantos usuarios como sea posible)

Te olvidas de lo más importante: un ancho de banda del copón xD, o sea dinero.

Creo que lo mejor sería usar un sistema de objetos/entidades en memoria del sistema(mucha memoria si).. que estuviese respaldado por una BD que actualizase datos críticos cada x tiempo(dinero de los jugadores y cosas asi).

Imagínate a 100 usuarios(que son muy pocos por cierto) mandando 15 paquetes a tu servidor cada segundo... si utilizases un SGBD no habría manera de aguantar ese ritmo, a no ser que tengas el server de microsoft y una amplia parcela donde colocarlo.  :D  

[Milinko]

Hola, hola...

Aunque tuviera un montón hebras dedicadas a la persistencia, es muy improbable que pudieran seguir el ritmo de cambio del estado del mundo (y mientras creáis que sí, multiplicad por 10 el número de usuarios, enemigos, objetos y demás que hay que mantener actualizado). El disco es un cuello de botella en este caso.

El cuello de botella en un MMOG es todo lo relacionado con la red; latencia, interfaces de red, control de paquetes, etc. En relación, el tiempo que se pueda destinar a la escritura/lectura de disco es muy pequeño en comparación.

¿Creéis vosotros que merece la pena usar una BD (con todo el follón adicional) para llevar el estado de un mundo virtual o es mejor tenerlo en memoria (en forma de objetos C++, variables, etc.) y que el server se encargue de serializarlo (con todo el follón adicional)?

Sin ninguna duda merece la pena usar una BD. Eso si, tambien es muy importante que se defina un buen modelo de datos y se optimizen al máximo las consultas.

¿Qué es más pesado de hacer? ¿El acceso a la base de datos con todos esos bonitos SELECTs y demás o hacerte un mini-gestor de bases de datos para mantener la persistencia de tu mundo virtual?

La opcion de hacerte tu propio mini-gestor de BBDD es más pesado de hacer, y además, tambien te puedes econtrar al final del camino con desagradables sorpresas de rendimiento, tolerancia a fallos, etc.  Yo opto por apoyarme en un SGBD (PostgreSQL, Mysql) para este tipo de juegos.

Espero haber servido de ayuda,

un saludo.

Milinko

[ethernet]

 Yo creo que un ejemplo claro de ese sistema son los servidores de IRC que soportan una cantidad de usuarios enormes (mas de 20000). Usan un gestor de base de datos propio simplisimo y mantienen la coherencia entre los diferentes servidores disponibles.

para mas info ver el code del ircd

saludos

[Milinko]

 Yo creo que el IRC no es un ejemplo extrapolable a toda la información que puedes manejar en un MMOG.

Bajo mi experiencia, el desarrollar un servidor multiplayer apoyandote en un SGBD (para guardar los datos de persistencia) es la mejor opción. Te ahorras un montón de tiempo y los tiempos de ejecución de las consultas, si la BD está optimizada, es irrelevante frente a otros problemas mayores que te puedes encontrar al desarrollar un juego de este tipo.

En Gamasutra puedes encontrar un artículo sobre la tecnología utilizada en un juego de este tipo: Dark Ages of Camelot, donde una de las cosas que alaban de la producción del juego fue la elección de MySql como gestor de bases de datos

"...we turned to a Linux-based freeware solution, MySQL, to manage Camelot's data storage, which so far has worked admirably."

Creo que la otra opción es reinventar la rueda, se emplea mucho más tiempo y hay que enfrentarse a multitud de problemas añadidos.

Milinko.

[jaure]

 No he hecho nunca un juego de estos.

Pero opino lo mismo, que Milinko, además en una BD, puedes utlizar las transacciones, para evitar que si estas actualizando tablas por haber realizando una acción (por ejemplo comprar un objeto) si ocurre un problema se quede a mitad, es decir que tengamos integridad transaccional en los datos (que te reste el dinero, pero no te añada el objeto comprado al inventario).

Un saludo

[ethernet]

 Yo no hablaba de un juego  en si, hablo del sistema para mantener  todos los datos integros. Desde luego mantener 28112 usuarios simultaneos no me parece ninguna tonteria:

Current local users: 2545 Max: 4341 (Martes, 24 de Febrero de 2004 -- 23:11 +01:00, since 20040213-05:14)
Current global users: 15360 Max: 28112 (Martes, 24 de Febrero de 2004 -- 23:11 +01:00, since 20040213-05:14)

Ademas de cada usuario mantiene una informacion en una base de datos.

Ahora me podeis decir en que no se parece un juego con muchos usuarios al irc EN ESTE ASPECTO ?

saludos

[gdl]

 Por lo que veo se confirman mis sospechas. Había releeido el código fuente de algunos serves (de UO y algunos MUDs/MOOs...) y suelen usar su propio sistema de persistencia, pero seguía sin gustarme la idea.

En efecto, el cuello de botella gordo es la red, pero siempre hay formas de minimizar el uso del ancho de banda, principalmente mediante cache y dead-rekoning. De todas las maneras, ya sería mucho bajar a 100Bytes/s y por mil usuarios da 100KB/s, es decir, que necesitarías una conexión de 1Mbps (en el mejor de los casos).

De todas las maneras, no nos engañemos, si algún día llego a tener 10 usuarios ya estoy contento y feliz. :D

Tampoco debemos olvidar que usar un SGBD tiene algunos inconvenientes, aunque en la cita que hace Milinko sobre el DAoC se intuye que los propios desarrolladores piensan que fue una buena idea usar MySQL. Y esa gente sí que está curtida en estas lides.

Tampoco descartaría mirarme lo del ircd, como dice ethernet, al menos para la gestión de usuarios. Aunque si me decido a poner MySQL, sería más fácil poner la gestión en la BD junto con el resto de los objetos del juego (O en otra base de datos similar en otro ordenador por motivos de seguridad).

Si me dejáis otra pregunta...

Ahora, vamos a suponer que tenemos la BD lista. ¿Cuál de los dos modelos de serialización usaríais?

1) Serializar el objeto en un bloque de datos y pasárselo a la BD con las ventajas de que la estructura de los objetos puede ser variable pero no se podrá leer directamente de la BD (un rollo para depurar).

2) Escribir cada atributo del objeto en un campo de alguna tabla de la BD con la ventaja de que podríamos hacer un SELECT * FROM.. y veríamos los atributos del objeto (muy bien para depurar) pero con la desventaja de que al serializar nos hemos de restringir a los campos definidos en la tabla.

Más o menos eso se traduce en ¿aprovecharías, además de la persistencia de la BD, su organización estructural (lo que se llama el esquema de la BD)?

Ya sé que estoy siendo un poco pesado, pero me gustaría sondear a la gente que seguro que saben más que yo ;)  ¡Gracias de nuevo!

 gdl

[ethernet]

Leyendo slashdot he encontrado esto:

http://www.acmqueue.com/modules.php?name=C...&pid=115&page=1

saludos :)

[gdl]

 slashdot: Es interesante la idea de generar un esquema de bases de datos a partir de las estructuras que use. Supongo que se necesitará un compilador de interfaces (tipo IDL o similar). Voy a ahondar un poco más a ver que encuentro sobre Ice.