HTML5 servidor push_motic nodo Java College terminando

Para aplicaciones web generales, la mayoría de los desarrolladores no son ajenos. En las aplicaciones web, el modo interactivo de solicitud/ respuesta se utiliza entre el navegador y el servidor. El navegador emite una solicitud, y el servidor genera la respuesta correspondiente de acuerdo con la solicitud. El navegador se procesa a la respuesta receptora a los usuarios. El formato de respuesta puede ser HTML, XML o JSON. Con el estilo de arquitectura REST y la popularidad de AJAX, el servidor utiliza más JSON como formato de datos de respuesta. La aplicación web utiliza el objeto xmlhttprequest para enviar la solicitud y actualizar dinámicamente el contenido de la página de acuerdo con los datos devueltos por el servidor. En términos generales, las operaciones de los usuarios en la página, como hacer clic o mover el mouse, activarán los eventos correspondientes. El objeto XMLHTTPREQUEST emite una solicitud, y la página tiene una actualización local después de que el servidor responde. Las deficiencias de este método son que los datos generados por el servidor no pueden ser notificados del navegador a tiempo, pero el navegador debe obtenerlos hasta que se envíe la próxima solicitud. Para algunas aplicaciones con requisitos de datos de alta tiempo, este retraso es inaceptable. Para satisfacer las necesidades de tales aplicaciones, existe la necesidad de algunas formas de empujar los datos del servidor al navegador para garantizar que los cambios de datos en el lado del servidor puedan notificarse a los usuarios por primera vez. Hay muchas soluciones comunes, que se pueden dividir en dos categorías. La diferencia entre estos dos métodos es si se basa en el protocolo HTTP. La práctica de no usar el protocolo HTTP es utilizar las nuevas especificaciones de WebSocket de HTML 5, y el método de usar el protocolo HTTP incluye rotación simple, tecnología Comet y el evento de empuje de servidor HTML 5 descrito en este artículo. Estas tecnologías se introducirán a continuación.

Antes de introducir el evento Push HTML 5 Server, primero introduzca parte de la cantidad de tecnología Push de datos junto al servidor mencionada anteriormente. El primero es WebSocket. La especificación de WebSocket es una parte importante de HTML 5. Ha sido compatible con muchos navegadores convencionales, y muchas aplicaciones desarrolladas basadas en WebSocket. Así como se expresa el nombre, WebSocket utiliza una conexión de chaqueta, basada en el protocolo TCP. Después de usar WebSocket, en realidad construye un conjunto de conexiones de palabras entre el servidor y el navegador, que se puede transmitir en datos de dos vías. La función de WebSocket es muy potente, y es flexible de usar, lo que puede ser adecuado para diferentes escenarios. Sin embargo, la tecnología WebSocket también es relativamente complicada, incluida la implementación del servidor y el lado del navegador diferente de las aplicaciones web comunes.

A excepción de WebSocket, otros métodos de implementación se basan en el protocolo HTTP para lograr el efecto del impulso de tiempo real. El primer método es la simple rotación, es decir, el navegador envía una solicitud al servidor de vez en cuando para preguntar si hay una actualización de datos. Este enfoque es relativamente simple y puede resolver el problema hasta cierto punto. Sin embargo, considere cuidadosamente el intervalo de tiempo de rotación. Si el intervalo entre la rotación es demasiado largo, hará que los usuarios no reciban los datos actualizados a tiempo;

La tecnología Comet ha mejorado las deficiencias de la rotación simple, utilizando consultas de ruedas largas. Cada solicitud de larga rotación, el servidor mantendrá la conexión en un período de apertura por un período de tiempo, en lugar de cerrarla inmediatamente después de completar la respuesta. La ventaja de esto es que dentro del período de tiempo en que se abre la conexión, la actualización de datos generada por el servidor puede devolverse al navegador a tiempo. Cuando se cierra una conexión larga, el navegador abrirá inmediatamente una nueva conexión larga para continuar la solicitud. Sin embargo, la implementación de la tecnología Comet requiere el soporte de una tercera biblioteca parcial en el servidor y el lado del navegador. En comparación resumida, las cuatro tecnologías diferentes mencionadas anteriormente no se recomiendan para su uso debido a sus defectos. La tecnología Comet no es parte del estándar HTML 5. Las especificaciones de WebSocket y la tecnología de empuje del servidor son parte del estándar HTML 5. Sin embargo, las especificaciones de WebSocket son más complicadas y son adecuadas para escenas que deben ser complicadas y la comunicación de datos de dos vías. Para escenarios simples de datos de datos del servidor, es suficiente usar eventos de empuje del servidor.

En términos de soporte del navegador, los eventos de empuje del servidor han sido compatibles con la mayoría de los escritorios y navegadores móviles, excepto IE. Los navegadores y versiones del evento Push Support Servidor incluyen: Firefox 6.0+, Chrome 6.0+, Safari 5.0+, Opera 11.0+, iOS Safari 4.0+, Opera Mobile 11.1+, Chrome para Android 25.0+, Firefox para andr OID 19.0.0 + y BlackBerry Browser 7.0+ et al. El apoyo de IE tiene una introducción detallada en los siguientes capítulos.

Se especifican las siguientes especificaciones de la especificación del evento Push del servidor.

La especificación de eventos de servidor es una parte integral de la especificación HTML 5. Esta especificación es relativamente simple, principalmente consta de dos partes: la primera parte es el protocolo de comunicación entre el servidor y el lado del navegador, y la segunda parte es el objeto EventSource utilizado por el navegador para usar JavaScript. El protocolo de comunicación es un protocolo simple basado en el texto puro. El contenido de la respuesta en el servidor es Text/Event-Stream. El contenido del texto de respuesta puede considerarse como un flujo de eventos, que se compone de diferentes eventos. Cada evento consta de dos partes: tipo y datos, y cada evento puede tener un identificador opcional. El contenido de diferentes eventos está separado por las líneas vacías (/r/n) que solo incluyen el automóvil Enter y el símbolo real. Los datos de cada evento pueden estar compuestos de múltiples líneas. La lista de códigos 1 ofrece un ejemplo de la respuesta del lado del servidor.

 Datos: Primer EventData: Second EventId: 100Event: MyEventData: Third EventId: 101: Este es un comentario Data: Fouteh EventData: Fours Event continúa

Como se muestra en la lista 1, cada evento está separado por una línea vacía. Para cada línea, el colon (:) es el tipo de línea anterior y el valor correspondiente detrás del colon. Los tipos posibles incluyen:

1. El tipo está en blanco, lo que indica que la línea es un comentario y será ignorado durante el procesamiento.
2. El tipo son datos, lo que significa que la línea contiene datos. Puede aparecer muchas veces al comienzo de los datos. Todas estas líneas son datos del incidente.
3. El tipo es el evento, lo que indica que el banco se utiliza para declarar el tipo de evento. Al recibir los datos, el navegador producirá un tipo de evento correspondiente.
4. El tipo es ID, lo que indica que la línea se usa para declarar el identificador del evento.
5. El tipo es volver a intentar, lo que indica que la línea se usa para declarar el tiempo de espera antes de que el navegador esté conectado después de desconectar la conexión.

En el código anterior, el primer evento solo contiene el primer evento de datos, que generará eventos predeterminados; El evento es Fours Event/Nfounth Eovent continúa. Cuando hay múltiples líneas de datos, los datos reales están conectados por los datos para el cambio de la línea.

Si los datos devueltos por el servidor contienen el identificador del evento, el navegador registrará el identificador del evento recientemente recibido. Si se interrumpe la conexión al servidor, cuando el extremo del navegador está conectado nuevamente, el logotipo de la última vez que el evento HTTP se obtiene. El servidor puede ser determinado por el identificador del evento enviado por el lado del navegador para determinar qué evento comienza a continuar la conexión.

Para la respuesta devuelta por el lado del servidor, el lado del navegador debe usar el objeto EventSource en JavaScript para su procesamiento. Eventsource utiliza un método de monitoreo de eventos estándar, que solo necesita agregar el método de procesamiento de eventos correspondiente al objeto. Eventsource proporciona tres eventos estándar, como se muestra en la Tabla 1.

Como se mencionó anteriormente, el servidor puede devolver un evento de tipo personalizado. Para estos eventos, puede usar el método AddEventListener para agregar el método de procesamiento de eventos correspondiente. La lista de códigos 2 ofrece un ejemplo del objeto EventSource.

 var es = nuevo eventsource ('eventos'); datos);});

Como se muestra arriba, después de crear específicamente el objeto EventSource, el método de procesamiento de eventos se puede agregar a través de los métodos OnMessage y AdDEventListener. Cuando el servidor tiene nuevos eventos, se llamará al método de procesamiento de eventos correspondiente. El papel de la propiedad OnMessage del objeto Eventsource es similar al de AdDEventListener ('Mensaje'), pero el atributo OnMessage solo admite un método de procesamiento de eventos. Después de introducir el contenido de especificación del evento Push del servidor, la implementación del servidor se introduce a continuación.

Se puede ver a partir de la descripción del protocolo de comunicación en la sección anterior que el evento Push del servidor es un protocolo más simple. La implementación del lado del servidor es relativamente simple. Se puede encontrar una variedad de diferentes tecnologías de servidor en la comunidad de código abierto. No es difícil desarrollarse. Este artículo utiliza Java como lenguaje de implementación del servidor. Implementación correspondiente del proyecto de servicio de ventaja de código abierto, consulte los recursos de referencia. El siguiente es un ejemplo específico para ilustrar cómo usar el proyecto Jetty-EventSource-Servlet. El ejemplo se usa para simular el movimiento aleatorio de un objeto en un espacio limitado. El objeto comienza desde una posición aleatoria, y luego selecciona aleatoriamente una dirección desde las direcciones superior, inferior, izquierda y derecha, y mueve una distancia aleatoria en esta dirección. El servidor cambia constantemente la posición del objeto y empuja la información de ubicación al navegador, que muestra el navegador.

： ： 一部分是用来产生数据的 org.eclipse.jetty.servlets.eventsource 接口的实现 ， 另一部分是作为浏览器访问端点的继承自 org.eclipse.jetty.servlets.eventsourceservlet 类的Implementación de servlet. El siguiente código proporciona una clase de implementación de la interfaz Eventsource.

Eventsurce interfaz clase de implementación de movimiento de movimiento de movimiento

 Public MotherEventsurce eventsurce {Private int width = 800; logger .getLogger (getClass (). getName ()); .NextInt (ancho); (LastEventId); .split (,); Pos [1], 10);} Catch (NumberFormateException e) {} if (isValidMove (xPOS, yPOS)) {x = xPos; Información); .Data (id) De acuerdo con la ubicación; , e); Move = GetMove (); Juzgando si la posición de movimiento actual es legal. xdir = nuevo int}; )};}}

El movimiento de movimiento necesita implementar el método Onopen, OnResume y Onclose de la interfaz EventsOurce. Los métodos Onopen y OnResume tienen un parámetro de la interfaz Eventsource.Emitter, que puede usarse para enviar datos. Los métodos contenidos en la interfaz eventsource.emitter incluyen datos, evento, comentarios, identificación y cierre, que corresponden a varios tipos de eventos en el protocolo de comunicación, respectivamente. El método OnResume también contiene un parámetro adicional LastEventid, que indica el identificador del último evento enviado por el último encabezado de ID-Event-ID.

La lógica principal de los eventos generados en el evento en la clase MovementEventSource está en el método de consulta. Este método contiene un ciclo ilimitado que cambia la posición cada 2 segundos, y al mismo tiempo envía la posición actualizada al final del navegador a través del método de datos de la posición de actualización a través del método de datos de la interfaz eventsource.emitter. Cada evento tiene un identificador correspondiente, y el valor del identificador es la posición en sí. Si el navegador se vuelve a conectar después de desconectar la conexión, el objeto se puede mover desde la última posición.

Es simple implementar el servicio del servicio que corresponde a la clase MotherEventSource. En la implementación del método NeweventSource, una clase de MovementEventSource debe devolverse, como se muestra a continuación. Cada vez que se establece el navegador, el servicio crea un objeto de una nueva clase de MovementEventSource para manejar la solicitud.

 Public Class Movementservlet ExtendseSartesServlet {@Override Eventsource NewsSource (httpservletRequest, string clientID) devuelve los nuevos movimiento de movimiento (800, 600, 20);}}

En la implementación del servidor, debe tenerse en cuenta que se debe agregar el soporte del filtro del servidor correspondiente. Este es el requisito del marco de continuaciones de embarcadero en el que se basa el proyecto Morder-Eventsource-Servlet, de lo contrario habrá errores en el caso. El método de agregar un filtro es agregar el contenido de configuración como se muestra a continuación en el archivo web.xml.

 <filter> <filter-name> Continuación </filtro-name> <filter-class> org.eclipse.jetty.continuation.continuationfilter </filter-class> </filtre> <filtre-ma pping> <filter-name> Continuación </filter-name> <url-pattern>/sse/*</url-Pattern> </filter-mapping>

La implementación del lado del navegador es relativamente simple. El siguiente código proporciona la implementación correspondiente. Use un cuadrado en la página para representar un objeto. Cuando se recibe un nuevo evento, la posición del bloque está en la página de acuerdo con la información de coordenadas dada en los datos del evento.

 var es = nuevo eventsource ('sse/movimiento'); [1];

Después de introducir el lado básico del servidor y el final del navegador, el soporte de IE más importante se introduce a continuación.

Un gran problema utilizando el objeto EventsOurce nativo del navegador es que IE no brinda soporte. Para proporcionar el mismo soporte en IE, generalmente hay dos formas. La primera forma es usar el objeto EventsOurce original en otros navegadores, mientras se utiliza la rotación simple o la tecnología de cometa en IE; . Este artículo utiliza la tecnología Polyfill, solo cargando una tercera biblioteca JavaScript de tercera parte en la página. La aplicación del código lateral del navegador no es necesario cambiar. Generalmente se recomienda utilizar un segundo método, porque de esta manera, solo se requiere una tecnología de implementación en el lado del servidor.

No es fácil proporcionar un objeto de plato primario similar en IE. En teoría, solo se necesita el objeto xmlhttprequest para obtener el contenido de respuesta del lado del servidor, y a través del análisis de texto, los eventos correspondientes se pueden extraer y se puede activar el método de procesamiento de eventos correspondiente. El problema es que el objeto xmlhttprequest en IE no admite el contenido de respuesta de la parte de obtención. Solo después de completar la respuesta se puede obtener. Porque el evento Push del servidor usa una conexión larga. Cuando la conexión siempre está abierta, el evento correspondiente no se puede activar a través del objeto xmlhttprequest, y el evento correspondiente no se puede activar. Más específicamente, cuando el ReadyState del objeto xmlhttprequest es 3 (ReadyState_interactive), su atributo ResponseText no se puede obtener.

Para resolver el problema de los objetos xmlhttprequest en IE, debe usar el objeto XDomainRequest introducido en IE 8. El papel del objeto XDomainRequest es enviar una solicitud AJAX de dominio cruzado. El objeto XDomainRequest proporciona el evento OnProgress. Cuando ocurre el evento OnProgress, se puede obtener algún contenido de la respuesta a través de la propiedad ResponseText. Esta es la mayor diferencia entre el objeto XdomainRequest y el objeto XMLHTTPRequest. Después de usar el objeto XDomainRequest para abrir la conexión al lado del servidor, cuando se generan los nuevos datos en el servidor, puede procesarse mediante el evento OnProgress del objeto XDomainRequest.

Sin embargo, debido al propósito original del objeto XdomainRequest es emitir solicitudes de AJAX de dominio cruzado considerando los problemas de seguridad del acceso al dominio cruzado, la limitación del objeto XDomainRequest también es estricto cuando se usa. Estas restricciones afectarán su implementación como un objeto EventSource. Las restricciones y soluciones específicas se muestran a continuación:

1. La respuesta del servidor debe contener el cabezal de origen de acceso de acceso de acceso, que se utiliza para declarar lo que está permitido la URL de los cuales los dominios lo permiten. *Significa permitir el acceso desde cualquier dominio, y este valor no se recomienda. Generalmente use el mismo dominio que la aplicación actual, restringiendo solo el acceso desde el dominio delantero.
2. La solicitud del objeto XDomainRequest no puede contener un cabezal HTTP personalizado, que limita el identificador del navegador recientemente recibido por el navegador. Este identificador solo se puede pasar a través de otras formas de solicitudes HTTP, como los parámetros solicitados por Get o el cuerpo de contenido de la solicitud posterior.
3. El tipo de contenido (tipo de contenido) del objeto XDomainRequest solo puede ser texto/simple. Esto significa que cuando se usa la solicitud de publicación, el marco utilizado por el servidor, como el servicio, no analizará automáticamente el contenido de la solicitud de publicación. El contenido de solicitud original solo se puede analizar en el servidor para obtener los valores de los parámetros.
4. La solicitud emitida por el objeto XDomainRequest no incluye ninguna información relacionada con la autenticación del usuario, incluidas las cookies. Esto significa que si el servidor necesita ser autenticado, otros métodos de solicitudes HTTP para aprobar la información de autenticación del usuario, como la ID de la sesión.

Debido a estas restricciones en el objeto XDomainRequest, la implementación del servidor también debe hacer los cambios correspondientes. Estos cambios incluyen devolver el cabezal de origen de control de acceso;

La biblioteca PolyFill utilizada en este artículo es el proyecto EventsOurce desarrollado por Yaffle en GitHub. Después de usar la biblioteca PolyFill y modificar la implementación del lado del servidor, puede usar el servidor para impulsar el evento en el navegador IE 8 y superior. Si necesita admitir IE 7, solo puede usar una consulta simple o tecnología de cometa. Consulte los recursos de referencia en el código de ejemplo de este artículo.

Si necesita empujar los datos del servidor al navegador, las tecnologías que pueden usarse en función de los estándares de especificación HTML 5 incluyen WebSocket y eventos de empuje del servidor. Los desarrolladores pueden elegir la tecnología correcta de acuerdo con las necesidades específicas de la aplicación. Si solo necesita expulsar los datos del servidor, el estándar del evento Push del servidor es más simple y fácil de lograr. Este artículo ha introducido el contenido estándar del evento Push del servidor, la implementación del servidor y el lado del navegador en detalle, y también analizó cómo admitir el navegador IE.