test - HTML 5 Websockets reemplazará a Comet?
websockets example javascript (6)
Parece que Websockets en HTML 5 se convertirá en un nuevo estándar para el servidor push.
¿Eso significa que el hack de push del servidor llamado Comet estará obsoleto?
¿Hay alguna razón por la que deba aprender cómo implementar el cometa cuando Websockets pronto (1-2 años) estará disponible en todos los principales navegadores?
Entonces podría usar Beaconpush o Pusher en su lugar hasta entonces ¿no?
¿Eso significa que el hack de push del servidor llamado Comet estará obsoleto?
WebSockets es capaz de reemplazar Comet, AJAX, Long Polling y todos los hacks para solucionar el problema cuando los navegadores web no pueden abrir un socket simple para comunicaciones bidireccionales con el servidor.
¿Hay alguna razón por la que deba aprender cómo implementar el cometa cuando WebSockets pronto estará disponible en todos los principales navegadores?
Depende de lo que "pronto" signifique para ti. Ninguna versión de Internet Explorer (pre IE 9) admite la API WebSockets aún, por ejemplo.
ACTUALIZAR:
Esta no fue una respuesta exhaustiva. Vea las otras respuestas, y @jvenema''s en particular, para obtener más información sobre este tema.
A medio plazo, websockets no reemplazará las soluciones cometas, no solo por la falta de compatibilidad con los navegadores, sino también por los Proxies HTTP . Hasta que la mayoría de los Proxies HTTP se actualicen para admitir las conexiones de websockets, los desarrolladores web tendrán que implementar soluciones alternativas basadas en técnicas de cometa para trabajar en redes "protegidas" con este tipo de proxies.
En el corto / mediano websockets será solo una optimización que se usará cuando esté disponible, pero aún necesitará implementar long-polling (cometa) para confiar cuando los websockets no estén disponibles si necesita hacer que su sitio web sea accesible durante una gran cantidad de clientes con redes / navegadores que no están bajo su control.
Con suerte, esto será abstraído por los frameworks de JavaScript y será transparente para los desarrolladores web.
Carta para el grupo de trabajo [ grupo de trabajo ] encargado de websockets, BiDirectional o HTTP iniciado por el servidor (hybi):
Descripción del grupo de trabajo
HTTP se ha utilizado con mayor frecuencia como un protocolo de solicitud / respuesta, lo que lleva a los clientes a sondear nuevos datos o a los usuarios que pulsan el botón Actualizar en sus navegadores. Las aplicaciones web recientes están encontrando formas de comunicarse con los servidores web en tiempo real, empujando los datos desde el servidor hacia el cliente tan pronto como estén disponibles. Sin embargo, estas aplicaciones actualmente solo pueden usar una variedad de mecanismos HTTP (por ejemplo, solicitudes de sondeo largas) para comunicarse bidireccionalmente con servidores web.
El grupo de trabajo Hypertext-Bidirectional (HyBi) buscará la estandarización de un enfoque para mantener las comunicaciones bidireccionales entre el cliente HTTP, el servidor y las entidades intermedias, lo que proporcionará una mayor eficiencia en comparación con el uso actual de solicitudes suspendidas.
HTTP todavía tiene un rol para jugar; es un sistema flexible orientado a mensajes. websockets fue desarrollado para proporcionar bidireccionalidad y evitar el largo problema de votación en conjunto. [ lo hace bien ]. pero es más simple que http. y hay muchas cosas útiles sobre http. sin duda habrá un progreso continuo enriqueciendo la comunicación bidireccional de http, ya sea cometa u otras tecnologías push. mi propio intento humilde es [ http://github.com/rektide/pipe-layer ].
Considere usar una biblioteca / marco de socket web que recaiga en el cometa en ausencia de soporte del navegador.
Salir Orbited y Hookbox.
Hay 2 piezas en este rompecabezas:
P: ¿Será necesaria la parte del "cometa" del lado del cliente?
A: Sí. Incluso en los próximos 2 años, no verá soporte completo para WebSockets en los "principales" navegadores. IE8, por ejemplo, no tiene soporte para ello, ni la versión actual de FireFox. Dado que IE6 fue lanzado en 2001, y todavía está por aquí hoy, no veo que WebSockets reemplace al cometa por completo en el corto plazo.
P: ¿Será necesaria la porción del lado del servidor del "cometa"?
A: Sí. Los servidores Comet están diseñados para manejar conexiones HTTP de larga duración, donde los servidores web "típicos" no lo hacen. Incluso si el lado del cliente es compatible con WebSockets, el lado del servidor aún deberá estar diseñado para manejar la carga.
Además, como mencionó "gustavogb", al menos ahora los WebSockets no son soportados adecuadamente en muchos Proxies HTTP, así que hasta que todos ellos se actualicen también, todavía necesitaremos algún tipo de mecanismo alternativo.
En resumen: el cometa, tal como existe hoy, no desaparecerá en el corto plazo.
Como nota adicional: las versiones de WebSockets que actualmente se implementan en Chrome y Safari son dos borradores diferentes, y el trabajo en el borrador "actual" todavía está en desarrollo, por lo que ni siquiera creo que sea realista decir que El soporte de WebSockets es funcional en este momento. Como curiosidad o para aprender, seguro, pero no como una verdadera especificación, al menos no todavía.
[Actualización, 2/23/11]
La versión de envío actual de Safari tiene una implementación interrumpida (no envía el encabezado correcto), Firefox 4 simplemente ha dejado de usar WebSockets, por lo que no se enviará habilitado, y IE9 tampoco se ve bien . Parece que Chrome es el único con una versión activa y habilitada de un borrador de especificaciones, por lo que WebSockets aún tiene un largo camino por recorrer.
Sí, porque "pronto" es un término muy resbaladizo. Muchas tiendas web todavía tienen que ser compatibles con IE6.
No, porque en los últimos tiempos ha surgido una erupción de sistemas y servidores de cometas que pronto hará que sea innecesario ensuciarse las manos en el sótano.
Sí, porque " pronto " es un término muy resbaladizo ...