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?.
pues todo depende del juego que tengas en mente.
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.
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.
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
Cita de: "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?.
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.
Cita de: "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
Muchos scripts de servidor web (por ejemplo, el PHP (http://www.php.net/manual/es/ref.sockets.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 (http://httpd.apache.org/docs/1.3/mod/core.html#timeout)).
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.
Para eso se inventaron los CGIs, procesos, etc. Crea un proceso server y consigue que algun servidor lo ejecute las 24horas.
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.
Cita de: "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).
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).
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
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
peticiones manuales via eventos de usuario, o automaticas via timers
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.
Cita de: "jazcks"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
Cita de: "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
lo que tu digas.
pero el ajax no es solo "peticiones hechas por usuario".
No me lo digas a mi, diselo a los google con su Gmail.
Ellos hacen polling con llamadas automaticas mediante ajax para saber si tienes un correo nuevo o no, sin tener que refrescar la pagina claro, o mejor aun, el gtalk via web que hay en gmail se basa en polling
Yo esto nunca lo he entendido. Cuando la gente dice que es posible con el navegador web hacer otra cosa distinta a pooling. Si el navegador no puede hacer de servidor, no puede recibir peticiones del servidor real, sino que tiene que llamar el.
Lo miremos como lo miremos, tiene que ser pooling. Muy bien hecho, con capas de cache, pero siempre sera pooling.
A no ser que pongamos una aplicacion java, un aplet, que pueda abrir sus propias conexiones, y se las apañe para abrir puertos a traves de routers y tal, porque esa es otra. Que una maquina interna se vea en internet..