Websockets. Pérdida de Internet, mensajes para mantener vivo, arquitectura de la aplicación, etc.

Question

Bueno, hay una gran cantidad de información sobre websockets. La tecnología en sí es increíble, no hay duda en este hecho. Y antes de comenzar a usarlos en mi aplicación solo quiero que la comunidad responda estas preguntas:

"... para mantener la presencia, la aplicación puede enviar mensajes de permanencia en vivo en el WebSocket para evitarlo de ser cerrado debido a un tiempo de espera inactivo ... "

" ... idealmente una versión futura de WebSocket admitirá el descubrimiento de tiempo de espera, por lo que puede decirle a la aplicación el período para mensajes de mantener vivo ... "

1. Esto se siente como un deja vu. Anteriormente tuvimos que sondear el servidor una vez a% period_time% para obtener la información actualizada necesaria. Con websockets tenemos que sondear el servidor websocket una vez a% period_time% con mensajes keep-alive para asegurarnos de que la conexión a Internet aún está activa/el servidor websocket todavía está funcionando. ¿Cuál es el beneficio?

   Y otra cosa con respecto a estos mensajes para mantener vivo. El protocolo Websocket tiene la ventaja de utilizar menos tráfico que HTTP (S). Si enviamos mensajes de mantener vivo, parece que la ventaja del tráfico desaparece. ¿O tal vez no?

2. ¿Cómo debo manejar la pérdida de de Internet en mi aplicación si uso websockets? Me refiero a la situación real cuando la conexión a Internet se pierde repentinamente (quiero decir que no ha sucedido ningún evento "navigator.offline"). ¿Debo usar algún tipo de función setTimeout para buscar mensajes de mantener vivo o hay una mejor manera de manejar esta situación?

3. REST nos da una idea clara de cómo debería funcionar una aplicación y cómo deberían ser las solicitudes. ¿Cuál es la mejor manera de hacer esto en aplicaciones basadas en websocket? ¿Debo simplemente tener (por ejemplo) mensajes codificados en JSON con el campo request.action? ¿Y cómo debería la aplicación realizar solicitudes PUT? Hay recursos de URL en el modelo REST para manejar esto, así que ¿debo usar la combinación de estos enfoques o tal vez hay algo simplista?

Answer 1

Creo que la mayoría de sus preguntas se pueden aclarar al comprender el verdadero propósito de WebSockets. WebSockets no fue diseñado principalmente para reemplazar cualquiera de las cosas que ya están en su lugar y funcionan bien. Por ejemplo, no fue diseñado para ser una versión de bajo costo de AJAX. El objetivo es proporcionar un canal de comunicación bidireccional de baja latencia y dúplex entre el navegador y el servidor. Su verdadero propósito es habilitar un nuevo dominio de aplicaciones web o mejorar las actuales que abusan de HTTP para lograr una comunicación bidireccional.

Con esto en mente permítanme comentar sobre sus puntos de bala:

1. El propósito de WebSockets periódica de ping/mensajes pong es doble: para mantener el canal se cierre por la TCP tiempo de espera y más detectar rápidamente cuando el canal está cerrado (esto es históricamente una debilidad de TCP). El propósito del sondeo HTTP/AJAX es evitar el hecho de que HTTP no es bidireccional (es decir, las encuestas de los clientes dan al servidor la oportunidad de enviar datos de vuelta). Los marcos de WebSocket ping/pong generalmente tienen 2 bytes de longitud. El sondeo HTTP/AJAX requiere encabezados completos, cookies, etc. que pueden sumar fácilmente más de un kilobyte por cada solicitud/respuesta. Incluso si envía un ping/pong 10 veces por segundo sobre WebSockets, es poco probable que incluso se compare con la sobrecarga de las encuestas HTTP/AJAX cada 2 segundos.Sin embargo, tenga en cuenta que las aplicaciones no tienen la capacidad de enviar mensajes ping/pong. Esto es entre el navegador y el servidor.

2. Si pierde la conexión a Internet, recibirá un evento onclose. Si su navegador no está haciendo mensajes ping/pong para usted, es posible que no reciba un onclose hasta que intente enviar un mensaje después de que la conexión de red se apague.

3. No reemplazaría un servicio RESTful que funcione con WebSockets. Haría un montón de trabajo de mapeo probablemente con muy poco beneficio (una vez más, WebSockets no está diseñado para reemplazar lo que ya funciona bien). Puedo imaginar situaciones en las que podría tener una combinación de ambas: REST para transferencia de estado, WebSockets para notificación de evento. P.ej. el servidor envía un mensaje de WebSocket que indica "algo cambiado" que hace que el cliente haga una solicitud REST para averiguar el cambio.

actualización:

Aclaración: se podría hacer RESTO sobre WebSockets pero es una falta de coincidencia en la filosofía. REST es un estilo de arquitectura que no tiene opiniones sobre el sistema de transporte subyacente. Es una arquitectura restringida: "cliente-servidor", "sin estado", "caché", "sistema en capas", "código bajo demanda" e "interfaz uniforme". WebSockets no está limitado por ninguno de esos; es un sistema de transporte de mensajes genérico. Puede restringir WebSockets para que sea RESTful pero no lo hace hasta que no entienda tanto REST como WebSockets y pueda identificar cuándo es correcto hacerlo.

Answer 2

"Por favor, dejen de decir palabras comunes y digan cuántos casos prácticos reales de uso de websockets en aplicaciones preparadas para producción conocen, excepto en chats y aplicaciones de bolsa de valores?"

He utilizado websockets para soporte multijugador en un juego de naves espaciales. Websockets es una tecnología realmente genial, pero también me resulta frustrantemente impredecible, lo que probablemente sea solo que yo sea un principiante y cometa algunos errores. Si tuviera más errores resueltos podría haber puesto un enlace, pero se cuelga demasiado, por lo que no lo tengo en un servidor en vivo en este momento.

Supongo que lo calificaría como una aplicación que no está lista para producción, pero hipotéticamente no veo por qué alguien más con más experiencia ya no lo hubiera hecho bien.