Hispanopedia Wiki
Articulo de referencia

Cometa (programación)

Comet es un modelo de aplicación web en el que una solicitud HTTPS mantenida durante un tiempo prolongado permite que un servidor web envíe datos a un navegador , sin que este l...

Hispanopedia WikiContenido en espanolLectura gratuita

Comet es un modelo de aplicación web en el que una solicitud HTTPS mantenida durante un tiempo prolongado permite que un servidor web envíe datos a un navegador , sin que este los solicite explícitamente. [ 1 ] [ 2 ] Comet es un término general que abarca múltiples técnicas para lograr esta interacción. Todos estos métodos se basan en características incluidas por defecto en los navegadores, como JavaScript , en lugar de en complementos no predeterminados. El enfoque Comet difiere del modelo original de la web , en el que un navegador solicita una página web completa a la vez. [ 3 ]

El uso de técnicas Comet en el desarrollo web es anterior al uso de la palabra Comet como neologismo para el conjunto de estas técnicas. Comet se conoce con varios nombres, entre ellos Ajax Push , [ 4 ] [ 5 ] Reverse Ajax , [ 6 ] Two-way-web , [ 7 ] HTTP Streaming , [ 7 ] y HTTP server push, [ 8 ] entre otros. [ 9 ] El término Comet no es un acrónimo, sino que fue acuñado por Alex Russell en su publicación de blog de 2006. [ 10 ]

En los últimos años , la estandarización y el amplio soporte de WebSocket y los eventos enviados por el servidor han dejado obsoleto el modelo Comet.

Historia

Applets de Java primitivos

La capacidad de integrar applets de Java en navegadores (a partir de Netscape Navigator 2.0 en marzo de 1996 [ 11 ] ) posibilitó la comunicación bidireccional continua, utilizando un socket TCP sin procesar [ 12 ] para la comunicación entre el navegador y el servidor. Este socket puede permanecer abierto mientras el navegador se encuentre en el documento que aloja el applet. Las notificaciones de eventos pueden enviarse en cualquier formato ( texto o binario ) y ser decodificadas por el applet.  

El primer marco de comunicación de navegador a navegador

La primera aplicación que utilizó comunicaciones de navegador a navegador fue Tango Interactive, [ 13 ] implementada entre 1996 y 1998 en el Northeast Parallel Architectures Center ( NPAC ) de la Universidad de Syracuse con financiación de DARPA . La arquitectura TANGO ha sido patentada por la Universidad de Syracuse. [ 14 ] El marco TANGO se ha utilizado ampliamente como herramienta de educación a distancia. [ 15 ] El marco ha sido comercializado por CollabWorx y utilizado en una docena de aplicaciones de mando y control y de entrenamiento en el Departamento de Defensa de los Estados Unidos .

Primeras solicitudes de Cometa

El primer conjunto de implementaciones de Comet data del año 2000, [ 16 ] con los proyectos Pushlets , Lightstreamer y KnowNow. Pushlets , un marco creado por Just van den Broecke, fue una de las primeras [ 17 ] implementaciones de código abierto. Pushlets se basaba en servlets Java del lado del servidor y una biblioteca JavaScript del lado del cliente. Bang Networks , una empresa emergente de Silicon Valley respaldada por el cofundador de Netscape, Marc Andreessen , realizó un intento con una financiación generosa para crear un estándar de notificaciones push en tiempo real para toda la web. [ 18 ]  

En abril de 2001, Chip Morningstar comenzó a desarrollar un servidor web basado en Java (J2SE) que utilizaba dos sockets HTTP para mantener abiertos dos canales de comunicación entre el servidor HTTP personalizado que él mismo diseñó y un cliente diseñado por Douglas Crockford ; en junio de 2001 ya existía un sistema de demostración funcional. Tanto el servidor como el cliente utilizaban un formato de mensajería que los fundadores de State Software, Inc. adoptaron como JSON, siguiendo la sugerencia de Crockford. El sistema completo, las bibliotecas del cliente, el formato de mensajería conocido como JSON y el servidor, conformaron el State Application Framework, del cual partes fueron vendidas y utilizadas por Sun Microsystems, Amazon.com, EDS y Volkswagen.

En marzo de 2006, el ingeniero de software Alex Russell acuñó el término Comet en una publicación de su blog personal. [ 19 ] El nuevo término era un juego de palabras con Ajax ( tanto Ajax como Comet son limpiadores domésticos comunes en los EE. UU.). [ 20 ] [ 21 ] [ 22 ]

En 2006, algunas aplicaciones expusieron esas técnicas a un público más amplio: la aplicación de chat web multiprotocolo de Meebo permitió a los usuarios conectarse a las plataformas de chat de AOL , Yahoo y Microsoft a través del navegador; Google añadió chat web a Gmail ; JotSpot , una startup adquirida posteriormente por Google, desarrolló un sistema de edición de documentos colaborativo en tiempo real basado en Comet. [ 23 ] Se crearon nuevas variantes de Comet, como el marco ICEfaces JSF basado en Java (aunque prefieren el término " Ajax Push " [ 5 ] ). Otros que anteriormente habían utilizado transportes basados ​​en applets de Java cambiaron a implementaciones puras de JavaScript. [ 24 ]

Implementaciones

Las aplicaciones Comet intentan eliminar las limitaciones del modelo web página por página y el sondeo tradicional al ofrecer una interacción bidireccional sostenida, utilizando una conexión HTTP persistente o de larga duración entre el servidor y el cliente. Dado que los navegadores y proxies no están diseñados teniendo en cuenta los eventos del servidor, se han desarrollado varias técnicas para lograr esto, cada una con diferentes ventajas y desventajas. El mayor obstáculo es la especificación HTTP 1.1, que establece que "esta especificación... anima a los clientes a ser conservadores al abrir múltiples conexiones". [ 25 ] Por lo tanto, mantener una conexión abierta para eventos en tiempo real tiene un impacto negativo en la usabilidad del navegador: el navegador puede bloquearse para enviar una nueva solicitud mientras espera los resultados de una solicitud anterior, por ejemplo, una serie de imágenes. Esto se puede solucionar creando un nombre de host distinto para la información en tiempo real, que es un alias para el mismo servidor físico. Esta estrategia es una aplicación de la fragmentación de dominio.

Los métodos específicos de implementación de Comet se dividen en dos categorías principales: transmisión continua y sondeo prolongado .

Transmisión

Una aplicación que utiliza Comet en tiempo real abre una única conexión persistente desde el navegador del cliente al servidor para todos los eventos de Comet . Estos eventos se gestionan e interpretan de forma incremental en el lado del cliente cada vez que el servidor envía un nuevo evento, sin que ninguna de las partes cierre la conexión. [ 3 ]

Las técnicas específicas para lograr la transmisión en directo de Comet incluyen las siguientes:

iframe oculto

Una técnica básica para aplicaciones web dinámicas consiste en utilizar un elemento HTML iframe oculto (un marco en línea , que permite a un sitio web incrustar un documento HTML dentro de otro). Este iframe invisible se envía como un bloque fragmentado , lo que implícitamente lo declara como de longitud infinita (a veces llamado "marco infinito"). A medida que ocurren eventos, el iframe se va llenando gradualmente con scriptetiquetas que contienen JavaScript para su ejecución en el navegador. Dado que los navegadores renderizan las páginas HTML de forma incremental, cada scriptetiqueta se ejecuta a medida que se recibe. Algunos navegadores requieren un tamaño mínimo específico del documento antes de que comience el análisis y la ejecución, que se puede obtener enviando inicialmente 1-2 kB de espacios de relleno. [ 26 ]

Una ventaja del método de iframes es que funciona en todos los navegadores comunes. Dos desventajas de esta técnica son la falta de un método fiable para el manejo de errores y la imposibilidad de rastrear el estado del proceso de llamada de la solicitud. [ 26 ]

Solicitud XMLHttp

El objeto XMLHttpRequest (XHR), una herramienta utilizada por las aplicaciones Ajax para la comunicación entre el navegador y el servidor, también puede emplearse para la mensajería Comet entre el servidor y el navegador, generando un formato de datos personalizado para una respuesta XHR y analizando cada evento mediante JavaScript del lado del navegador; dependiendo únicamente de que el navegador active la función de devolución onreadystatechangede llamada cada vez que reciba nuevos datos.

Ajax con votación a largo plazo

Ninguno de los transportes de transmisión mencionados anteriormente funciona en todos los navegadores modernos sin efectos secundarios negativos. Esto obliga a los desarrolladores de Comet a implementar varios transportes de transmisión complejos, alternando entre ellos según el navegador. En consecuencia, muchas aplicaciones Comet utilizan sondeo prolongado (long polling), que es más fácil de implementar en el lado del navegador y funciona, como mínimo, en todos los navegadores que admiten XHR. Como su nombre indica, el sondeo prolongado requiere que el cliente sondee al servidor en busca de un evento (o conjunto de eventos). El navegador realiza una solicitud de estilo Ajax al servidor, que permanece abierta hasta que el servidor tiene nuevos datos para enviar al navegador, los cuales se envían al navegador en una respuesta completa. El navegador inicia una nueva solicitud de sondeo prolongado para obtener eventos posteriores. El RFC 6202 de la IETF, "Problemas conocidos y mejores prácticas para el uso de sondeo prolongado y transmisión en HTTP bidireccional", compara el sondeo prolongado y la transmisión HTTP. Las tecnologías específicas para lograr el sondeo prolongado incluyen las siguientes:

Sondeo largo de XMLHttpRequest

En general, el sondeo largo de XMLHttpRequest funciona como cualquier uso estándar de XHR. El navegador realiza una solicitud asíncrona al servidor, que puede esperar a que los datos estén disponibles antes de responder. La respuesta puede contener datos codificados (normalmente XML o JSON ) o código JavaScript para que el cliente lo ejecute. Al finalizar el procesamiento de la respuesta, el navegador crea y envía otra solicitud XHR para esperar el siguiente evento. De esta forma, el navegador mantiene siempre una solicitud pendiente con el servidor, que se responderá cuando ocurra cada evento.

Sondeo largo con etiquetas de script

Aunque cualquier transporte de Comet puede funcionar entre subdominios , ninguno de los transportes mencionados anteriormente puede utilizarse entre diferentes dominios de segundo nivel (SLD), debido a las políticas de seguridad del navegador diseñadas para prevenir ataques de secuencias de comandos entre sitios (XSS ). [ 27 ] Es decir, si la página web principal se sirve desde un SLD y el servidor Comet se encuentra en otro SLD (que no tiene habilitado el uso compartido de recursos entre orígenes ), los eventos de Comet no pueden utilizarse para modificar el HTML y el DOM de la página principal mediante esos transportes. Este problema puede evitarse creando un servidor proxy delante de una o ambas fuentes, haciendo que parezcan originarse en el mismo dominio. Sin embargo, esto suele ser indeseable por razones de complejidad o rendimiento.

A diferencia de los iframes o los objetos XMLHttpRequest, scriptlas etiquetas pueden apuntar a cualquier URI , y el código JavaScript de la respuesta se ejecutará en el documento HTML actual. Esto crea un riesgo potencial de seguridad para ambos servidores involucrados, aunque el riesgo para el proveedor de datos (en nuestro caso, el servidor Comet) se puede evitar usando JSONP .

Se puede crear un transporte Comet de sondeo prolongado creando scriptelementos dinámicamente y estableciendo su origen en la ubicación del servidor Comet, que luego envía JavaScript (o JSONP) con algún evento como carga útil. Cada vez que se completa la solicitud de script, el navegador abre una nueva, al igual que en el caso del sondeo prolongado XHR. Este método tiene la ventaja de ser compatible con varios navegadores y, al mismo tiempo, permite implementaciones entre dominios. [ 27 ]

Alternativas

Las tecnologías nativas del navegador son inherentes al término Comet. Los intentos por mejorar la comunicación HTTP sin sondeo han provenido de múltiples frentes:

  • La especificación HTML 5 producida por el Grupo de Trabajo de Tecnología de Aplicaciones de Hipertexto Web (WHATWG) especifica los llamados eventos enviados por el servidor , [ 28 ] que definen una nueva interfaz JavaScript EventSourcey un nuevo tipo MIME text/event-stream.
  • El funcionamiento de la API WebSocket de HTML 5 especifica un método para crear una conexión persistente con un servidor y recibir mensajes a través de una devolución de llamada. [ 29 ]onmessage
  • El protocolo Bayeux de la Fundación Dojo mantiene los protocolos de transporte específicos del navegador y define un protocolo de nivel superior para la comunicación entre el navegador y el servidor, con el objetivo de permitir la reutilización del código JavaScript del lado del cliente con múltiples servidores Comet y permitir que el mismo servidor Comet se comunique con múltiples implementaciones de JavaScript del lado del cliente. Bayeux se basa en un modelo de publicación/suscripción, por lo que los servidores que lo admiten tienen la publicación/suscripción integrada. [ 30 ]
  • El protocolo BOSH , desarrollado por la fundación de estándares XMPP, emula una transmisión bidireccional entre el navegador y el servidor mediante dos conexiones HTTP síncronas.
  • El objeto JSONRequest, propuesto por Douglas Crockford , sería una alternativa al objeto XHR. [ 31 ]
  • Uso de complementos, como applets de Java o el software propietario Adobe Flash (que utiliza el protocolo RTMP para la transmisión de datos a aplicaciones Flash). Estos tienen la ventaja de funcionar de forma idéntica en todos los navegadores con el complemento adecuado instalado y no necesitan depender de conexiones HTTP, pero la desventaja de requerir que el complemento esté instalado.
  • Google anunció [ 32 ] una nueva API de canal para Google App Engine , [ 33 ] que implementa una API similar a Comet con la ayuda de una biblioteca JavaScript del cliente en el navegador. Esta API ha sido descontinuada. [ 34 ]

Véase también

Notas

Referencias

  1. ↑ Krill, Paul (24 de septiembre de 2007). "La alianza AJAX reconoce las combinaciones de aplicaciones" . InfoWorld . Recuperado el 20 de octubre de 2010 .
  2. ↑ Crane, Dave; McCarthy, Phil (13 de octubre de 2008). Comet y Reverse Ajax: La próxima generación de Ajax 2.0 . Apress . ISBN 978-1-59059-998-3.
  3. 1 2 Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push" . Webreference.com. Archivado del original el 18 de octubre de 2010. Recuperado el 20 de octubre de 2010 .
  4. ↑ Egloff, Andreas (5 de mayo de 2007). Ajax Push (también conocido como Comet) con Java Business Integration (JBI) (Discurso). JavaOne 2007, San Francisco, California : Sun Microsystems , Inc. Recuperado el 10 de junio de 2008 .{{cite speech}}: CS1 mantenimiento: ubicación ( enlace )
  5. 1 2 "Ajax Push" . ICEfaces.org . Consultado el 23 de octubre de 2014 .
  6. ↑ Crane, Dave; McCarthy, Phil (julio de 2008). Comet y Reverse Ajax: La próxima generación de Ajax 2.0 . Apress. ISBN 978-1-59059-998-3.
  7. 1 2 Mahemoff, Michael (junio de 2006). "Web Remoting" . Patrones de diseño Ajax . O'Reilly Media . págs. 19, 85. ISBN  0-596-10180-5.
  8. ↑ Double, Chris (05/11/2005). "Más sobre Ajax y el envío de datos desde el servidor" . Diferentes formas de realizar el envío de datos desde el servidor . Recuperado el 05/05/2008 .
  9. ↑ Nesbitt, Bryce (1 de noviembre de 2005). "La técnica de carga lenta/AJAX inversa" . Simulación de envío de datos desde el servidor en un navegador web estándar . Archivado del original el 8 de febrero de 2006. Consultado el 6 de mayo de 2008 .
  10. ↑ Russell, Alex (2006-03-04). "Comet: Datos de baja latencia para el navegador" . Recuperado el 2014-11-02 .
  11. ↑ "Netscape.com" . Archivado del original el 15 de noviembre de 1996. Consultado el 16 de agosto de 2017 .{{cite web}}: CS1 maint: bot: estado de la URL original desconocido ( enlace )
  12. ↑ "java.net.Socket (Java 2 Platform SE v1.4.2)" Archivado el 19 de mayo de 2009 en Wayback Machine .
  13. ↑ Beca, Lukasz (1997). "TANGO - un entorno colaborativo para la World Wide Web" . Syracuse University SURFACE . Northeast Parallel Architecture Center, Facultad de Ingeniería e Informática . Recuperado el 27 de febrero de 2016 .
  14. ↑ Podgorny, Marek; Beca, Lukasz; Cheng, Gang; Fox, Geoffrey C.; Jurga, Tomasz; Olszewski, Konrad; Sokolowski, Piotr; Walczak, Krzysztof; PL (20 de junio de 2000), Patente de Estados Unidos: 6078948 - Plataforma independiente de la infraestructura y marco de colaboración para la formación de comunidades virtuales con salas virtuales para sesiones colaborativas , archivado del original el 9 de mayo de 2017 , recuperado el 27 de febrero de 2016.
  15. ↑ Baer, ​​Troy (1999). "Experiencias con el uso de TANGO Interactive en un taller distribuido" (PDF) . Centro de recursos compartidos principales de CEWES . CEWES MSRC/PET TR/99-21. Archivado del original (PDF) el 8 de marzo de 2021. Recuperado el 27 de febrero de 2016 .
  16. ↑ "CometDaily: Comet y tecnología de empuje" . Archivado del original el 13 de noviembre de 2007. Consultado el 15 de diciembre de 2007 .
  17. ↑ Just van den Broecke (1 de marzo de 2000). “ Pushlets: Envío de eventos desde servlets a navegadores cliente DHTML. Archivado el 4 de agosto de 2014 en Wayback Machine ”. JavaWorld. Consultado el 1 de agosto de 2014.
  18. ↑ Borland, John (1 de abril de 2001). "¿Quedará obsoleto el botón de "actualizar"?" . CNET Networks . Consultado el 22 de julio de 2008 .
  19. ↑ Alex Russell (3 de marzo de 2006). “ Comet: Datos de baja latencia para el navegador. Archivado el 12 de agosto de 2008 en Wayback Machine ”. Blog de Alex Russell. Consultado el 29 de noviembre de 2007.
  20. ↑ K. Taft, Darryl (12 de mayo de 2006). "Microsoft elimina Comet del conjunto de herramientas AJAX" . eWEEK.com . Consultado el 21 de julio de 2008 .
  21. ↑ Orbitado: El cometa como herramienta para el público general: OSCON 2008 - Conferencias O'Reilly, del 21 al 25 de julio de 2008, Portland, Oregón.
  22. ↑ Presentación en vivo de Enterprise Comet y Web 2.0 archivada el 20 de mayo de 2008 en Wayback Machine.
  23. ↑ Dion Almaer (29 de septiembre de 2005). “ Jotspot Live: Toma de notas grupal en vivo ” (entrevista con Abe Fettig). Ajaxian. Consultado el 15 de diciembre de 2007.Matt Marshall (15 de diciembre de 2006). “ Renkoo lanza un servicio para eventos, justo a tiempo para programar cócteles navideños ”. Venture Beat. Consultado el 15 de diciembre de 2007.
  24. ↑ Clint Boulton (27 de diciembre de 2005). “ Las startups se suben al carro de AJAX ”. DevX News. Consultado el 18 de febrero de 2008.
  25. ↑ Protocolo de transferencia de hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes, sección 6.4 . IETF. Consultado el 29 de julio de 2014.
  26. 1 2 Holdener III, Anthony T. (enero de 2008). "Diseño de página con marcos que no lo son". Ajax: La guía definitiva . O'Reilly Media . pág. 320. ISBN  978-0-596-52838-6.
  27. 1 2 Flanagan, David ( 17 de agosto de 2006). "13.8.4 Cross-Site Scripting". JavaScript: La guía definitiva . O'Reilly Media . pág. 994. ISBN  0-596-10199-6.
  28. ↑ Ian Hickson, ed. (27-10-2007). "6.2 Eventos DOM enviados por el servidor" . HTML 5 - Llamada a comentarios . WHATWG . Recuperado el 07-10-2008 .
  29. ↑ Hickson, Ian (23 de abril de 2009). "La API de WebSocket" . W3C . Consultado el 21 de julio de 2009 .
  30. ↑ Alex Russell; et al. (2007). "Protocolo de Bayeux - Bayeux 1.0draft1" . Fundación Dojo . Recuperado el 14 de diciembre de 2007 . 
  31. ↑ Crockford, Douglas (17 de abril de 2006). "JSONRequest Duplex" . Una alternativa a XMLHttpRequest para el envío de datos iniciado por el servidor de larga duración . Recuperado el 5 de mayo de 2008 .
  32. ↑ App, The. (2 de diciembre de 2010) Blog de Google App Engine: Felices fiestas del equipo de App Engine: lanzamiento del SDK 1.4.0 . Googleappengine.blogspot.com. Consultado el 12 de abril de 2014.
  33. ↑ Paul, Ryan. (6 de diciembre de 2010) App Engine obtiene la API de transmisión y tareas en segundo plano más largas . Ars Technica. Recuperado el 12 de abril de 2014.
  34. ↑ "Paquete com.google.appengine.api.channel" . 16/11/2019 . Consultado el 30/04/2020 . Esta API ha sido descontinuada.
  • "Comet Daily" . Archivado del original el 4 de enero de 2008. Consultado el 29 de noviembre de 2007. Comet Daily ofrece información sobre las técnicas de Comet.*