Tengo un cliente de navegador Javascript que abre un WebSocket (usando socket.io) para solicitar un inicio de proceso de larga duración, y luego recibe una devolución de llamada cuando el proceso finaliza. Cuando recibo la devolución de llamada, actualizo la página web para que el usuario sepa que el proceso se ha completado.

Esto funciona bien, excepto en mi iPad cuando cambio a otra aplicación y luego vuelvo (nunca recibe la devolución de llamada, porque supongo que la aplicación no está en línea en ese momento). Supongo que sucederá lo mismo en una computadora portátil u otra computadora que duerme mientras espera la devolución de llamada.

¿Existe una forma estándar (o alguna forma) de lidiar con este escenario? Gracias.

Como referencia, si desea ver la página del problema, se encuentra en http://amigen.perfectapi.com/

9
Steve Campbell 13 ene. 2012 a las 19:36

1 respuesta

La mejor respuesta

Hay un par de cosas a considerar en este escenario:

Detecta que la aplicación se apaga o está en línea

Consulte: Eventos en línea y fuera de línea.

Cuando su aplicación detecta el evento online después de que la computadora se activa, puede obtener cualquier información que se haya perdido.

Para los navegadores web más antiguos, deberá hacer esto de una manera más inteligente. En Pusher hemos agregado una verificación de ping-pong entre el cliente y el servidor. Si el cliente no recibe un ping dentro de un cierto período de tiempo, sabe que hay un problema de conexión. Si el servidor envía un ping y no lo recupera con un tiempo determinado, sabe que hay un problema.

Un mecanismo de ping pong es definido en la especificación, pero aún no se ha definido una forma de enviar un ping o pong en la API de WebSocket.

Obteniendo información perdida

La mayoría de los servidores en tiempo real solo envían mensajes a los clientes conectados. Si un cliente no está conectado, tal vez debido a una perturbación temporal de la red o su computadora ha estado inactiva por un tiempo, esos clientes perderán el mensaje.

Algunos marcos brindan acceso a los mensajes a través de un historial / caché. Para aquellos que no lo hacen, deberá detectar el problema (como se indica arriba) y luego buscar los mensajes perdidos. Una buena forma de hacerlo es proporcionando una marca de tiempo o un ID de secuencia con cada mensaje para que pueda hacer una llamada a su servidor web para decir "dame todos los mensajes desde X".

8
leggetter 16 ene. 2012 a las 19:02
7
Solo para que conste, Socket.IO también implementa un 'ping pong', llamado latido. Esto comprobará si la conexión sigue activa o no. Se puede configurar el intervalo de latidos (ping).
 – 
alessioalex
17 ene. 2012 a las 13:47
+1 para comentar. Información útil. Gracias.
 – 
leggetter
17 ene. 2012 a las 19:15