Una duda sobre multiplayers

[Diferencial]

Pues me ha surgido una duda sobre un juego multiplayer en internet, ¿seria bueno usar un servicio web para este tipo de aplicaciones o es más correcto usar sockets?.

[vicho]

pues todo depende del juego que tengas en mente.

[Diferencial]

Por lo que he estado mirando, el servicio web iria bien si el juego fuese por turnos, pero si lo que quieres es que funcione en tiempo real me imagino que lo ideal seria por sockets. Ejemplo de juego seria tetris y en el caso de turnos pues ajedrez.

[gdl]

Por lo que yo sé, si usas web, las peticiones son siempre del cliente al servidor. Es decir, que si el estado del juego cambia en el servidor, no hay manera de que éste se lo diga al cliente (vamos, que el jugador no se entera que le han matado).

La forma de "resolver" esto es haciendo que el cliente le pida cada cierto tiempo al servidor los cambios de estado. Esto es la típica técnica de "polling" bien conocida y con los siguentes problemas:

1) Si el refresco es cada muy poco tiempo, consumes mucho ancho de banda.
2) Si el refresco es cada mucho tiempo, la actualización del cliente es lenta (el jugador notará lag o le matarán antes de que sepa qué ha pasado).

No es fácil saber el tiempo de refresco adecuado y, en algunos casos (como bien decías los juegos rápidos en tiempo real) no será posible. Por otra parte, usar sockets resuelve todo estos problemas pero:

- Si intentas usar un servidor web para los sockets, has de saber que tienen un temporizador y sólo pueden estar conectados cierto tiempo.
- Si no usas un servidor web... pues te tienes que currar el servidor y el cliente por lo que se multiplican por 100 o por 1000 las horas de esfuerzo.

Nunca he desarrollado un juego web ni basado en sockets. Así que tampoco me hagas caso 100%. Lo mismo existe un truco que evita estos problemas.

[Diferencial]

Muchas gracias por la respuesta, esta muy interesante. Lo que no acabo de entender esta parte.
Si intentas usar un servidor web para los sockets, has de saber que tienen un temporizador y sólo pueden estar conectados cierto tiempo

[Tei]

Pues me ha surgido una duda sobre un juego multiplayer en internet, ¿seria bueno usar un servicio web para este tipo de aplicaciones o es más correcto usar sockets?.

Normalmente la latencia haria imposible utilizar un servidor web para servir los frames en un juego FPS a una velocidad razonable.

En un juego de estrategia de tablero como risk, de cartas, o algo asi, se puede utilizar perfectamente. Aunque la web no se diseño para algo asi.

[gdl]

Muchas gracias por la respuesta, esta muy interesante. Lo que no acabo de entender esta parte.
Si intentas usar un servidor web para los sockets, has de saber que tienen un temporizador y sólo pueden estar conectados cierto tiempo

Muchos scripts de servidor web (por ejemplo, el PHP) tienen un API de sockets. Es decir, que podrías usarlos como servidores sockets/http híbridos. Sin embargo, para evitar que el script se quede colgado, los servidores web suelen tener un tiempo de espera máximo (por ejemplo Apache).

Así que aunque uses el API de sockets, no puedes tener un proceso ejecutándose continuamente en el servidor web. Podría hacerse mediante una llamada externa al script (si estás en Linux/Unix, con crond o algo así) pero cada vez nos estamos alejando más del servidor web y nos acercamos a un servidor dedicado.

[tamat]

Para eso se inventaron los CGIs, procesos, etc. Crea un proceso server y consigue que algun servidor lo ejecute las 24horas.

[Diferencial]

Digamos que tengo un servidor dedicado de esta forma no hay problema, ahora con la respuesta que has dicho gdl sobre el servidor apache...no veas ahora entiendo el porque me pasaba eso, yo estube usando los sockets de php, pero no conseguia que se quedara el dichoso server socket abierto siempre para recibir más conexiones porque se cerraba al cabo de un tiempo. Me volvio loco porque no descubri el porque hasta ahora. Por otra parte tamat estube mirando eso de los cgi y no entendi un carajo asi que si sabes algo de la materia te lo agradeceria yo y muchos que tengan dudas sobre esto si comentas de que va. Gracias.

[Repoker]

Por lo que yo sé, si usas web, las peticiones son siempre del cliente al servidor. Es decir, que si el estado del juego cambia en el servidor, no hay manera de que éste se lo diga al cliente (vamos, que el jugador no se entera que le han matado).

Esto es incompleto. El servidor puede actualizar el estado del cliente mediante llamadas asíncronas tipo AJAX. Hay 18905613957132 librerías y tutoriales sobre cómo hacer esto en internet. Para ver un ejemplo: mail.google.com (de ahí que no tenga que recargar la página cada vez que quieres abrir un mensaje).

[jazcks]

pero estamos en lo mismo, que el servidor te diga algo mediante ajax, es en realidad hacer polling desde el cliente (llamadas ajax cada X tiempo)

aunque claro, tambien hay diversas tecnicas para optimizar este polling

[Repoker]

Estás seguro ? Que yo sepa cualquier llamada tipo AJAX es provocada por eventos de usuario ... yo a eso no lo llamaría polling :P

[jazcks]

peticiones manuales via eventos de usuario, o automaticas via timers

[Tei]

El pooling es ineficiente, y se acumula a la ineficiencia general de la web, y los navegadores web.
"la web" para lo que es guena es para servir ficheros estaticos (o lo que ella crea ficheros estaticos) y cachearlos.
Con esto en mente, un juego es como su peor pesadilla, porque genera infinitud de estados o bien no cacheables, o si son cacheables que solo se usaran una vez (el peor caso para un cache).

Ademas PHP es muy posible que tenga leaks de memoria, o que no sea muy amigo de devolver la memoria usada, por eso para procesos que van a vivir mucho tiempo, como un servidor, puede ser una mala opcion. A no ser que implementes en el propio PHP que el servidor se reinicie cada pocas horas, lo cual no lo veo una locura.

[Repoker]

peticiones manuales via eventos de usuario, o automaticas via timers

Venga va.. pa ti la perra gorda.

PS: Así hasta la conciencia humana puede considerarse un polling automático de grupos de neuronas .. xD