Joder con los japos... ¡cómo suben los tíos!

 
Espérate vicho... yo también programaba más de cinco horas al día cuando estudiaba.... ya verás cuando tengas que currar cómo se reducen las cosas.

Si hablamos de Windows, se le puede enviar un mensaje de teclado a cualquier ventana. Sólo basta conocer el manejador (HWND). Mírate el API de Win32 y, especialmente, el mensaje WM_CHAR.

Para leer la cosa está más jodidilla.

 
Hola, hola...

Que yo sepa hay tres formas de utilizar la red (y más o menos cualquier dispositivo de E/S).

- Síncrono: Cada vez que se quiera algo, hay que esperar a que finalice.
- Asíncrono: Cada vez que se quiera algo, se envía la instrucción y luego ya te responderán. Es el clásico funcionamiento por interrupciones.
- No bloqueante: Cada vez que se quiera algo, no esperamos a que finalice, pero tampoco te notifican el final. Es el típico "polling".

Teniendo en cuenta que esperar es realmente bloquear la hebra en la que estemos, mi pregunta es: ¿qué método es más adecuado cuando el número de conexiones es alto y todas tienen que ser atendidas?

Es el típico caso de un servidor para un juego MMORPG. Tengo, digamos, mil jugadores simultáneos (clientes). Hay que atenderlos a todos, pero si uso un método síncrono necesito una hebra para cada cliente (y muchos SO no aguantan mil hebras, o si lo aguantan, les duele). El método asíncrono no está disponible en todos los API (o quizás sí, la verdad es que tampoco me he empollado tan fondo los sockets, TLIs y otras hierbas). El método no bloqueante es ineficiente, por eso del polling (preguntar cada dos por tres si algo ha llegado).

Como veis, vayamos por donde vayamos, baches nos encontramos.

¿Alguna idea esperanzadora para este alma atormentada? (nooo)  

 
Hola, hola...

En matemáticas es el espacio formado por todas las posibles derivadas de una función en un punto. No sé en programación qué es específicamente y tampoco estoy muy convencido de lo que te acabo de decir... si hay algún matemático que lo explique para la gente de a pie....  :lol:  

 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.

Hola, hola...

Como los monitores TFT (y plasma) se conectan a la salida RGB de toda la vida de Dios, existe el retrazo vertical aunque no hay un haz físico que vuelva a la esquina superior izquierda de la pantalla. Es decir, que de la tarjeta de video y por el cable pasa la señal de retrazo vertical, aunque luego el monitor actualice la imagen de otra manera.

En definitiva: desde el punto de vista del software, existe aún el retrazo.

  gdl

 
A mí siempre me gustó la isométrica, pero comprendo que la más inmersiva es la primera persona.

 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

 
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.

 
Hola, hola....

Creo que MChiz se acerca mucho....

Esta web puede ser interesante:

http://www.geocities.com/spur4444/prog/con...d_pointers.html

Sobre todo el "listing 3".

De hecho, el escribir

Código [Seleccionar] Expand


int MiFuncion( const cMiTipo *dato )


es llamado "estilo C++" y el poner

Código [Seleccionar] Expand


int MiFuncion( cMiTipo const *dato )


es llamado "estilo C". Pero claro, sólo son estilos. La semántica es la misma. Lo que no es lo mismo es poner

Código [Seleccionar] Expand


int MiFuncion( cMiTipo *const dato )


a no ser que no sea un puntero, sino una referencia... pero eso es otro rollo. Ya no quiero liar mas.

Feliz programación.