son - websocket server php

¿Comet está obsoleto ahora con los eventos enviados por el servidor y WebSocket? (4)

¿O los eventos enviados por el servidor y WebSocket reemplazan las técnicas de cometas?

Abordaré esta respuesta desde una perspectiva tanto terminológica como histórica.

Como escribí en esta otra respuesta , podemos usar uno de los varios términos generales para referirnos al conjunto de tecnologías disponibles para enviar eventos de forma asíncrona desde un servidor web a un cliente web (y viceversa). El término " tecnología Push " se ha utilizado durante quince años (para una breve historia de la tecnología Push, puede ver este viejo documento que escribí hace muchos años - revelación completa: soy el creador de Lightstreamer). Ahora, el término " Web Streaming " está ganando consenso entre los analistas de TI (ver Gartner, "Cool Vendors in Application and Integration Platforms, 2012", de Massimo Pezzini y Jess Thompson, 11 de abril de 2012).

El aspecto importante es que estamos hablando de comunicación basada en web, es decir, aprovechando los protocolos web. Hay muchos protocolos y tecnologías de mensajería que no están basados en la Web (la mayoría de los MOM, por ejemplo) y no los consideramos como parte de la Tecnología Push (o Transmisión por Internet).

Dicho esto, puede distinguir entre dos subcategorías de Tecnología Push (o Web Streaming):

Basado en HTTP
Basado en websockets

Tanto HTTP como WebSockets son protocolos web.

Si explota los mecanismos de inserción basados en HTTP, puede identificar:

Transmisión HTTP
Encuesta larga HTTP
Encuesta HTTP

Tradicionalmente, el término " Comet " (codificado en 2006 por Alex Russell) se ha referido tanto a HTTP Streaming como a HTTP Polling. Pero considere que las primeras implementaciones de HTTP Streaming se remontan a 2000 , mucho antes de que se acuñara el término Comet (los ejemplos son Pushlets y Lightstreamer).

Ahora WebSockets simplifica la implementación de Web Streaming, especialmente para el canal "hacia atrás" (mensajes enviados desde el navegador al servidor). Para obtener una explicación más detallada sobre las peculiaridades del canal anterior a través de HTTP, consulte la parte final de este artículo que escribí para CometDaily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/

Como señaló Phil, Comet sigue siendo necesario y probablemente lo será por algunos años más, ya que no solo hay navegadores antiguos (incluido IE9, que no es compatible con WebSockets ...) sino también infinitas piezas de intermediarios de red que no lo hacen. hablar WS. Por ejemplo, hemos visto que algunos operadores de telefonía móvil en algunos países (por ejemplo, Vodafone Italia) admiten WSS pero bloquean WS. Por lo tanto, un mundo sin los "hacks" del cometa está aún muy lejos ... Y, a título personal, permítanme agregar que nunca me ha gustado el término "hack" aplicado al cometa (o, desde un punto histórico más correcto de vista, aplicado a HTTP Streaming y HTTP Long Polling). Habiendo trabajado en estas técnicas durante 12 años, puedo decir que hemos sido capaces de refinarlas tanto que ellas mismas se han convertido en una tecnología completa, completamente confiable y utilizada todos los días en muchos escenarios de producción críticos (en finanzas, aeroespacial, etc.). y militar, por nombrar algunas industrias).

Ahora, imaginemos un mundo donde los WebSockets son universalmente compatibles y Comet ya no es necesario. ¿Qué obtienes exactamente? Bueno, solo un transporte bidireccional, nada más ... En la parte superior de esto, necesita crear todo: un protocolo de mensajería (quizás basado en pub / sub), una interfaz del lado del servidor para hablar con el código de su servidor, y un buen conjunto de técnicas de optimización y algoritmos para gestionar el flujo de datos, incluida la gestión del ancho de banda, la combinación de datos, la regulación automática, la entrega delta, etc. Lo bueno es que los protocolos de mensajería y los mecanismos de optimización ya han sido implementados por buenas soluciones Comet . Por lo tanto, ampliar los servidores de Comet para que sean compatibles con WebSocket es la evolución natural que todos los proveedores hemos implementado.

Entonces, en pocas palabras, en un futuro no muy cercano, WebSockets puede hacer que los transportes Comet queden obsoletos, pero tendrá que absorber todas las capas superiores ya implementadas y bien probadas en los servidores Comet tradicionales.

Al principio pensé que WebSockets se daría cuenta de cometa. No son una alternativa . Sin embargo, después de algunas discusiones, Alex Russell , el creador de "Comet" me corrigió y convenció de que ese no era el caso.

Comet, como dice @kanaka, es un conjunto de principios para simular la comunicación bidireccional entre el cliente y el servidor (el empuje del servidor es la mitad de la solución y ahora es proporcionado por Server-Sent Events y la API de origen del evento).

Sin embargo, las soluciones Comet son piruetas porque funcionan de manera inconsistente en los navegadores web. Por eso Alex Russell dice:

A continuación, ¿son los sockets web una forma de cometa? ¿O es Comet solo los hacks HTTP? Voy a ir por la última definición. La frase y los hacks probablemente deberían cabalgar hacia el atardecer juntos. Yo, por mi parte, doy la bienvenida a nuestros amos en tiempo real no HTTP. En la medida en que podamos olvidarnos de los navegadores antiguos (y, por supuesto, estoy haciendo mi parte: http://google.com/chromeframe ), todos podemos abordar "Web Sockets" y la necesidad de un paraguas en particular. se va.
Entonces, concentrémonos en eso: ¿cómo podemos lograr que los usuarios ingresen a un nuevo y brillante auto de navegador? ¿Qué tipo de oferta podemos hacerles sobre la riqueza y las experiencias en tiempo real que puede ofrecer una aplicación basada en WebSockets? El cometa es sobre el pasado. Vamos a hacer el futuro real.

Ahora estoy con Alex en este caso. Sin embargo, Comet, las soluciones HTTP, no se volverán obsoletas hasta que:

El soporte del navegador es del 100% y no necesitamos reservas para <IE10. No creo que los usuarios de Firefox, Safari y Opera vayan a ser un problema. Puede haber un pequeño porcentaje de usuarios que ignoran los avisos de actualización automática para los navegadores como Firefox pero no muchos.
Los fabricantes de antivirus (como Avast) inician el soporte de las tecnologías web HTML5 y detienen su software que interfiere con la conectividad.
Parte de la infraestructura de Internet se actualiza para garantizar el soporte de WebSockets. En mi experiencia, conectado a través de WSS a través del puerto 443 (una conexión segura de WebSocket) normalmente significa que las conexiones se abren paso a través de Firewalls y Proxies, pero queremos que WS sobre el puerto 80 siempre sea compatible.

Si bien WebSocket proporciona al nivel más fundamental una forma de comunicación bidireccional entre un cliente y un servidor en el contexto de la Web y HTTP, es una forma simple de comunicación.

Comet proporciona más funcionalidad en la parte superior de WebSocket (de hecho, cometd incluso admite websocket), para las características:

Como publicar / suscribir y canales de comunicación.
alternativa a las técnicas de comunicación del servidor <-> cliente anterior cuando websocket no está disponible

Comet es un conjunto de principios de tecnología / patrones de comunicación que normalmente se implementan utilizando HTTP largo-encuesta. Permite que un servidor envíe datos al navegador a pedido (es decir, inserción de servidor). Las implementaciones actuales de los cometas requieren un poco de Javascript complejo en el lado del cliente y soporte desde el lado del servidor (para solicitudes de larga duración).

Server-Sent Events es una API de navegador estándar (HTML5) para habilitar este tipo de inserción de servidor a pedido. Puede pensar que los eventos enviados por el servidor toman lo que se ha hecho con un Javascript complejo y lo empujan hacia abajo en el propio navegador.

WebSockets permite que un navegador establezca una conexión permanente de dúplex completo / bidireccional a un servidor compatible con WebSocket. No requiere que el cliente siga haciendo solicitudes HTTP periódicas al servidor para mantener la conexión como con AJAX / long-poll. Una vez que se establece la conexión, la sobrecarga por mensaje es muy baja (unos pocos bytes) en comparación con la sobrecarga con HTTP / HTTP de encuesta larga. Puede usar WebSockets para la inserción eficiente del servidor, pero esta es solo una aplicación.

También hay bibliotecas que se basan en la capa de transporte AJAX / cometa / WebSockets para proporcionar administración de sesión, canales, difusión, pubsub, etc. CometD es un ejemplo de esto. Otro ejemplo popular es Socket.IO . Ambos admiten WebSockets si está disponible para el transporte subyacente, pero también son compatibles con AJAX estándar / encuesta larga si WebSockets no está disponible.