Play framework longpolling en el juego en línea

Question

Estoy trabajando en un juego de navegador con el marco de juego, y definitivamente necesito longpolling, pero no entiendo muy bien cómo usarlo. WebSockets sería perfecto para esto, pero aún no es compatible con muchos navegadores.

Esto es lo que quiero hacer: Cuando el usuario inicia una sesión, y navega al controlador de juego, quiero iniciar una conexión, y mantenerla abierta. Quiero hacer esto para todos los usuarios que están en línea, por lo que puedo mostrar una lista de ellos en el sitio, para que puedan jugar entre ellos. Miré the documentation, pero no entiendo cómo podría implementarlo en mi caso. Como simplemente no hay nada que quiera calcular (en el ejemplo, están generando un pdf) solo quiero que la conexión permanezca abierta.

Lo que también me pregunto es, ¿cómo debo hacer un seguimiento de todas estas conexiones abiertas? En este momento, solo tengo una columna online en mi tabla de usuarios en la base de datos, que actualizo. Así que cada vez que alguien se conecta, tengo que actualizar la base de datos. ¿Hay mejores formas de hacer esto o está bien?

Y, por último, suponiendo que todo lo anterior funciona. Cuando el jugador A, selecciona al jugador B para jugar: ¿cómo notifico esto al jugador B? ¿Acabo de enviar algún código JSON, y cambiar la página con javascript, en el lado del jugador B, o lo envío a una página totalmente diferente? No estoy seguro de cómo comunicarme cuando se establecen las dos conexiones y el juego ha comenzado.

Answer 1

En primer lugar, creo que debe apreciar la diferencia entre Websockets y Long Polling.

websockets crea una conexión y la mantiene abierta hasta el navegador termina la sesión, a través de algunos JavaScript o al usuario pasar de la página. Esto le daría la naturaleza deseada de lo que está solicitando. Si mira el ejemplo de chat en la descarga de Play, verá cómo se maneja una aplicación de chat completa usando Websockets. Además de la respuesta de Pere con respecto a la apatridia de Play. Los creadores de Play han sugerido que una única conexión de Websocket, independientemente de cuánto tiempo esté abierta y cuántas solicitudes se envíen de regreso, se considera una transacción única. Por lo tanto, no es necesario guardar en la base de datos entre cada solicitud de Websocket (de nuevo, puede ver que no se guarda nada en el ejemplo de chat). Con este método, se espera que guarde los detalles cuando finalmente se cierre Websocket o, en realidad, todos los Websockets, según su caso de uso.

largo de sondeo en el otro lado se abre una conexión con el servidor, y el servidor simplemente espera hasta que haya algo que enviar de vuelta al cliente. Si necesita enviar datos al servidor, lo haría como una solicitud AJAX por separado, por lo que efectivamente tendría dos solicitudes abiertas a la vez. No necesariamente sabe cuándo un usuario cierra la sesión, a menos que envíe una solicitud cuando abandonan la página, para avisarle al servidor que se han ido, pero esto no siempre es exitoso. Long Polling puede funcionar, pero no es una solución tan clara como Websockets, pero como dices, aún no es ampliamente compatible.

Mi sugerencia sería estudiar el ejemplo del chat (ya que tiene una versión larga de sondeo y Websockets). Esta será la forma más efectiva de comenzar a trabajar con sus requisitos.

En cuanto a su consulta final sobre cómo notificar al otro jugador. En Long Polling, simplemente responderá a la solicitud suspendida con algunos JSON. Con websockets, enviarías un evento al cliente. Una vez más, ambos enfoques se pueden deducir claramente del ejemplo del chat.

También tengo written a Blog post en Websockets, que pueden ayudarlo a comprender este proceso un poco mejor.

Answer 2

En la parte Websocket, como puede ver here (primera respuesta), la compatibilidad no es tan mala, y tiene un respaldo de Javascript si hay algún problema con el navegador. Esto simplificaría su escenario, ya que una encuesta larga puede ser más complicada de administrar.

Sobre la cuestión de hacer el seguimiento, como El juego es sin estado que tiene que almacenar la bandera en la base de datos y retirarlo cuando se cierre la conexión. De lo contrario, estás rompiendo la apatridia.

Acerca de la notificación, usted tiene que enviar algún mensaje a B, pero no los mueva a otra página, ya que puede ser confuso y causar la mala experiencia del usuario. Usa Json para mostrar un mensaje (en un div) alertándolos sobre el inicio del juego o la solicitud para jugar.

Answer 3

No estoy usando el marco "play".

Pero he estado investigando y retocando últimamente con encuestas largas basadas en http. ¡Websockets, si está disponible, es mucho más apropiado para mensajes en tiempo real!

En cuanto a las encuestas largas, encontré que el uso de una analogía de "camión de carga" me ayudó a razonar acerca de un sondeo prolongado con bastante eficacia. He aquí una pequeña nota que escribí sobre el tema:

http://dvb.omino.com/blog/2011/http-comet-realtime-messages/

Tal vez usted o greppers futuros puede resultar útil.

Answer 4

También es posible que desee echar un vistazo al proyecto Juggernaut que se basa en node.js y Redis y le ofrece una "conexión en tiempo real entre sus servidores y sus navegadores cliente". Al usar un cliente Java Redis como Jedis, ¡debería ser capaz de integrar todo con el framework Play!