2008-08-21 9 views
122

Por supuesto que conozco Ajax, pero el problema con Ajax es que el navegador debe sondear el servidor con frecuencia para ver si hay datos nuevos. Esto aumenta la carga del servidor.¿Hay alguna manera de PULSAR datos del servidor web al navegador?

¿Existe algún método mejor (incluso el uso de Ajax) que no sea interrogar al servidor con frecuencia?

+0

@Rachel - Actualizaciones en vivo para que pueda ver lo que otros están haciendo. Bueno para sitios como StackOverflow y para aplicaciones web para colaboración como Google docs. –

+0

Cualquiera que haga este tipo de cosas en 2016 probablemente encuentre websockets como una mejor opción para este tipo de comunicación. – Shadow

+0

No estoy seguro de que exista. Para hacerlo conceptualmente más simple para la aplicación, supongo que podría implementar una capa de transporte sobre las solicitudes de sondeo, y así eliminar la responsabilidad de la votación de la lógica de la aplicación. Tal vez alguien incluso ya implementó esto? Editar: Aparentemente se llama reverse Ajax y Comet, pero hasta ahora parece que tiene que implementarlo usted mismo. Una biblioteca de JavaScript para esto, ¿alguien? –

Respuesta

9

Busque en Comet (una parodia en el hecho de que Ajax es un agente de limpieza y también lo es Comet) que es básicamente "Ajax inverso". Tenga en cuenta que esto requiere una conexión de servidor de larga duración para que cada usuario reciba notificaciones, así que tenga en cuenta las implicaciones de rendimiento al escribir su aplicación.

http://en.wikipedia.org/wiki/Comet_(programming)

0

Una vez que se abre una conexión con el servidor se puede mantener abierta y el servidor puedan insertar contenido en un largo hace algún tiempo que lo hice con el uso de multipart/x-mixed-replace pero esto no funcionó en el IE.

Creo que puede hacer cosas inteligentes con la votación que hace que funcione más como presionar al no enviar el contenido sin cambiar los encabezados pero dejando la conexión abierta, pero nunca he hecho esto.

1

Hay otros métodos. No estoy seguro de si son "mejores" en su situación. Podría tener un applet de Java que se conecte al servidor en la carga de la página y espere a que el servidor envíe cosas. Sería un poco más lento en la puesta en marcha, pero permitiría que el navegador reciba datos del servidor de forma infrecuente, sin votación.

-1

También puede consultar Java Pushlets si está utilizando páginas jsp.

1

Es posible lograr lo que se pretende mediante el uso de conexiones HTTP persistentes.

Revisa el Comet article en wikipedia, ese es un buen lugar para comenzar.

No proporciona demasiada información, pero si está buscando construir algún tipo de sitio basado en eventos (a'la digg spy) o algo así, probablemente esté buscando implementar un código oculto. IFRAME que se conecta a una url en la que la conexión nunca se cierra y luego debe enviar las secuencias de comandos desde el servidor al cliente para realizar las actualizaciones.

4

Le sugiero encarecidamente invertir algo de tiempo en Comet, pero no conozco una implementación real o biblioteca que pueda usar. Para una especie de "panel de control de callcenter" de una aplicación web que implicaba actualizar el agente y el estado de la cola de llamadas para un Callcenter activo, desarrollamos una solución interna que funciona, pero está muy lejos de una biblioteca que podría usar. .

Lo que hicimos fue implementar un pequeño servicio en el servidor que habla con el sistema telefónico, espera nuevos eventos y mantiene una fotografía de la situación. Este servicio proporciona un pequeño servidor web.

Nuestros clientes web se conectan a través de HTTP a este servidor web y solicitan la última foto (codificada en XML), la muestra y luego vuelve a aparecer, solicitando la nueva foto.El servidor web en este punto puede:

  • Devuelve la nueva foto, si es que existe
  • Bloquear el cliente durante unos segundos (30 en nuestra configuración) a la espera de algún acontecimiento que ocurr y cambiar la fotografía. Si no se generó ningún evento en ese punto, devuelve la misma foto, solo para permitir que la conexión permanezca activa y no se agote el tiempo del cliente.

De esta manera, cuando los clientes sondean, obtiene una respuesta en 0 a 30 segundos como máximo. Si ya se generó un nuevo evento, lo obtiene de inmediato), de lo contrario, se bloquea hasta que se genere un nuevo evento.

Básicamente se trata de sondeo, pero es un poco inteligente para no sobrecalentar el servidor web. Si Comet no es tu respuesta, estoy seguro de que esto podría implementarse usando la misma idea, pero usando AJAX o codificando más extensamente en JSON para obtener mejores resultados. Esto fue diseñado antes de la era AJAX, por lo que hay mucho margen de mejora.

Si alguien puede proporcionar una implementación liviana real de esto, ¡genial!

4

Una alternativa interesante a Comet es usar sockets en Flash.

0

Puede probar nuestro Comet Component - aunque es extremadamente experimental ...!

1

Puede usar una aplicación Flash/Flex en el cliente con BlazeDS o LiveCycle en el lado del servidor. Los datos se pueden enviar al cliente utilizando una conexión RTMP. Tenga en cuenta que RTMP usa un puerto no estándar. Pero puede volver fácilmente al sondeo si el puerto está bloqueado.

1

Puede valer el Meteor Server que es un servidor web diseñado para COMET. Nice demo y también lo utiliza twitterfall.

+1

versión más nueva en https://www.meteor.com/ y se está generalizando. –

35

Sí, se llama Reverse Ajax o Comet. Comet es básicamente un término general para diferentes formas de abrir solicitudes HTTP de larga duración con el fin de enviar datos en tiempo real a un navegador web. Recomendaría StreamHub Push Server, tienen algunas demostraciones geniales y es mucho más fácil comenzar a usar que cualquiera de los otros servidores. Consulte Getting Started with Comet and StreamHub Tutorial para una introducción rápida. Puede utilizar Community Edition, que está disponible para descargar de forma gratuita pero está limitado a 20 usuarios simultáneos. La versión comercial vale la pena solo por el soporte, además de obtener SSL y Desktop .NET & adaptadores de cliente Java. La ayuda está disponible a través del Google Group, hay un buen grupo de tutoriales en la red y también hay un GWT Comet adapter.

+0

Definitivamente el camino a seguir, una vez que lo implemente usted mismo, se dará cuenta de lo mucho que hay que hacer: reconexión, larga encuesta, transmisión de iframes, compatibilidad con navegadores cruzados, HTTPS ... – Corehpf

+1

Una explicación de qué es Comet ayudaría esta respuesta –

+0

@Satir: agregó una explicación rápida. Otras respuestas tienen enlaces al artículo de Wikipedia. – Nosrama

27

Hoy en día se debe utilizar WebSockets. Este es el estándar 2011 que permite iniciar las conexiones con HTTP y luego actualizarlas a una comunicación bidireccional entre el cliente y el servidor basada en mensajes.

Puede iniciar fácilmente la conexión desde javascript:

var ws = new WebSocket("ws://your.domain.com/somePathIfYouNeed?args=any"); 
ws.onmessage = function (evt) 
{ 
    var message = evt.data; 
    //decode message (with JSON or something) and do the needed 
}; 

El manejo-lado del servidor dependerá de su pila Tenchnology.

+1

Vs eventos enviados por el servidor: http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource –

+7

Estoy totalmente de acuerdo ... Usar HTTP para comunicación bidireccional es como pensar en llamadas REST para hacer que Mario salte sobre las conchas de tortuga ... es una locura. No NECESITA realizar solicitudes y esperar respuestas por simple botón empuja a las personas .... Simplemente no lo hace. HTTP es un protocolo de documento. Protocolo de Transferencia de Hipertexto. Ajax Push es una forma increíblemente compleja de eludir HTTP para hacer lo que WebSocket hace por diseño. Deja de ser tonto y utiliza la herramienta adecuada para el trabajo. –

4

Otra forma más estándar es SSE (Server-Sent Events, also known as EventSource, después del objeto JavaScript).

+0

La última versión de la especificación W3C http://www.w3.org/TR/2009/WD-eventsource-20091029/ redirige a https://html.spec.whatwg.org/multipage/comms.html#server- eventos enviados –

Cuestiones relacionadas