1. Qué es SignalR:
ASP.NET SignalR es una biblioteca de clases proporcionada para simplificar el proceso de añadir contenido web en vivo a aplicaciones por parte de desarrolladores. La funcionalidad web en tiempo real se refiere a permitir que el código del servidor envíe contenido activamente a los clientes en cualquier momento, en lugar de que el servidor espere una solicitud del cliente (antes de devolver el contenido).
Todos los tipos de funcionalidad web "en vivo" pueden añadirse a tu aplicación ASP.NET usando SignalR. El ejemplo más común son las salas de chat, pero podemos hacer mucho más que eso. Consideremos las siguientes situaciones: los usuarios deben actualizar constantemente la página web para ver los datos más recientes; O recuperar (y mostrar) nuevos datos en la página implementando sondeos largos, y luego puedes considerar usar SignalR para hacerlo. Por ejemplo: paneles de control y aplicaciones de monitorización; Aplicaciones colaborativas (por ejemplo, varias personas editando documentos al mismo tiempo); Actualizaciones de progreso del trabajo y formularios de presentaciones en tiempo real, etc.
SignalR también es adecuado para tipos más recientes de aplicaciones web que requieren actualizaciones de alta frecuencia desde el servidor, como el juego en tiempo real. Aquí tienes un buen ejemplo: ShoorR.
SignalR proporciona una API sencilla para que los usuarios creen llamadas a procedimientos remotos (RPC) de servidor a cliente que pueden ser fácilmente accedidas desde el lado del servidor. Código de red. SignalR también incluye conexiones (por ejemplo, eventos de conexión y desconexión) y agrupación de conexiones.
SignalR puede gestionar las conexiones automáticamente. Y te permite enviar mensajes de difusión a todos los clientes conectados, igual que una sala de chat. Por supuesto, además del envío masivo, también puedes enviar mensajes a clientes concretos. La conexión entre el cliente y el servidor es persistente, a diferencia del protocolo HTTP tradicional, que requiere restablecer la conexión para cada comunicación.
SignalR soporta la función de "push del servidor", donde el código del servidor puede llamar al código cliente en el navegador mediante llamadas a procedimientos remotos (RPC) en lugar de solicitudes actualmente comúnmente usadas en la web, el modelo de procesamiento correspondiente.
Las aplicaciones SignalR pueden extenderse a miles de clientes usando Service Bus, SQL SERVER o Redis.
SignalR es de código abierto y se puede acceder a través de GitHub.
2. SignalR y WebSocket
ignalR utiliza el método de transporte WebSocket, siempre que es posible. Y cambiar automáticamente al método de transporte antiguo (por ejemplo, conexión HTTP larga). Sin duda puedes escribir tu aplicación directamente con WebSockets, pero usar SignalR significa que tendrás más funcionalidades extra sin tener que reinventar la rueda. Lo más importante es que puedes centrarte en la implementación empresarial sin pensar en crear código compatible por separado para el cliente antiguo. SignalR también permite evitar preocuparse por las actualizaciones de WebSocket, ya que SignalR seguirá actualizándose para soportar cambios en los métodos de transporte subyacentes y así proporcionar una interfaz de acceso consistente para aplicaciones en diferentes versiones de WebSockets.
Por supuesto, puedes crear una solución que solo use transporte WebSocket, y SignalR proporciona todas las funciones que puedas necesitar para escribir tu propio código, como recurrir a otros métodos de transporte y modificar tu aplicación para implementaciones más recientes de WebSocket.
3. Transporte y regreso
SignalR es una abstracción de la tecnología de transporte necesaria para implementar funciones en tiempo real entre clientes y servidores. SignalR inicia primero la conexión con HTTP y comprueba si el WebSocket está disponible; si es así, actualiza a la conexión del WebSocket. WebSocket es el método de transmisión más ideal para SignalR porque hace el uso más eficiente de la memoria del servidor, tiene la latencia más baja y funciones subyacentes completas (como la comunicación full-duplex entre cliente y servidor), pero también tiene los requisitos más estrictos: el servidor debe usar Windows Server 2012 o Windows 8, y al mismo tiempo. .NET Framework versión 4.5 y superiores. Si no se cumplen estos requisitos, SignalR intentará usar un método de transmisión alternativo para conectarse.
4. Envío en HTML5
El método de transporte utilizado depende de si el navegador cliente soporta HTML5, de lo contrario se utilizará el método de transporte antiguo.
WebSocket (si tanto el servidor como el navegador soportan WebSocket). WebSocket es la única forma de establecer una conexión bidireccional verdadera y duradera tanto en el lado cliente como en el servidor. Por supuesto, WebSocket también tiene los requisitos más estrictos: solo es compatible con las últimas versiones de IE, Chrome y FF, y solo está parcialmente implementado en otros navegadores como Opera y Safari.
El servidor envía eventos, también conocidos como EventSource (si el navegador soporta eventos de envío del servidor, básicamente todos los navegadores excepto IE soportan esta función).
5. Transmisión por cometa
Los siguientes tipos de transporte se basan en el modelo de aplicación web Comet, donde el navegador o cliente mantendrá una larga solicitud de conexión HTTP y el servidor puede enviar datos al cliente sin una solicitud explícita del cliente.
Forever Frame (es decir, solo) Forever Frame creará un IFrame oculto que envía una solicitud al servidor que no se completará. El servidor envía scripts continuamente al cliente y es ejecutado inmediatamente por el cliente, es decir, una conexión unidireccional en tiempo real del servidor al cliente. La conexión cliente-servidor utiliza una conexión diferente a esa conexión. Por ejemplo, una solicitud HTML estándar crea una nueva conexión para cada dato enviado.
El long polling de Ajax no crea una conexión persistente, sino que hace sondeos haciendo solicitudes constantes al servidor. Espera a que el servidor responda y cierra esta conexión en cada conexión, y luego haz una nueva solicitud inmediatamente. Por supuesto, esto causará cierto retraso cuando la conexión se reinicie y se reconecte.
Para información sobre los métodos de transporte soportados por diversas configuraciones, véase Plataformas soportadas. (Por ejemplo, requiere 8 o más, otros navegadores son la versión actual -1)
Proceso de selección del método de transferencia
La siguiente lista muestra cómo SignalR decide qué tipo usar para la transmisión.
IE8 y anteriores, usa sondeo largo.
Si JSONP está configurado (es decir, el parámetro jsonp está configurado como verdadero al conectar), usa sondeo largo.
Si usas una conexión entre dominios (es decir, el extremo SignalR y la página no están en el mismo dominio), entonces usa WebSockets si se cumplen las siguientes condiciones:
El cliente soporta el Intercambio de Recursos entre Dominio (CORS), véase CORS en para más detalles
El cliente soporta WebSocket
El servidor soporta WebSocket
Si no se cumple alguna de las condiciones anteriores, se utiliza una encuesta larga. Para más información sobre conexiones entre dominios, consulte Cómo establecer conexiones entre dominios.
Si no configuras el uso de JSONP y la conexión no es multidominio, usa WebSocket, por supuesto, siempre que tanto el cliente como el servidor soporten WebSocket.
Si el cliente o servidor no soporta WebSockets, utiliza el servidor para enviar eventos.
Si el servidor envía un evento no disponible, utiliza un Forever Frame.
Si Forever Frame no está disponible, usa sondeo largo.
Transmisión de monitores
Puedes ver qué método de transporte utiliza tu aplicación activando el registro del Hub y desde la consola del navegador.
Para habilitar el registro, añade el siguiente comando a la aplicación cliente:
nnection.hub.logging = verdadero;
6. Inspección y transporte:
Puedes ver qué método de transporte utiliza tu aplicación activando el registro del Hub y desde la consola del navegador. Para habilitar el registro, añade el siguiente comando a la aplicación cliente:
nnection.hub.logging = verdadero;
$.connection.hub.logging = verdadero;
En IE, pulsa F12 para abrir las herramientas de desarrollo y haz clic en la pestaña Consola.
En Chrome, pulsa Ctrl+Shift+J para abrir la consola
Al observar el registro en la consola, puedes ver el método de transmisión que está usando SignalR.
7. Transporte designado:
Negociar el método de transmisión requiere cierta cantidad de tiempo y los recursos del servidor/cliente. Si se conoce el entorno cliente, entonces se puede especificar el método de transporte cuando se inicia la conexión para mejorar el rendimiento. El siguiente código demuestra el uso del long polling de Ajax directamente al inicio de la conexión si se sabe que el cliente soporta algún otro protocolo:
conexión.inicio({ transporte: 'longPolling' });
Si quieres que un cliente negocie el transporte en un orden específico, puedes especificar el orden en el que se intenta la negociación. El código de abajo muestra cómo intentar usar primero WebSockets y usar sondeos largos directamente tras el fallo.
conexión.inicio({ transporte: ['webSockets','longPolling'] });
Las constantes de cadena especificadas por el usuario se definen de la siguiente manera:
WebSockets
forverFrame
serverSentEvents
longPolling
8. Conexiones y centros La API de SignalR incluye dos modelos de comunicación cliente-servidor: conexiones persistentes y hubs.
Una conexión representa un punto final sencillo para enviar un mensaje único, agrupado o de difusión. La API PersistentConnection (representada por la clase PersistentConnection en el código .NET) ofrece a los desarrolladores acceso directo al protocolo de comunicación subyacente de SignalR. Los desarrolladores que hayan utilizado APIs basadas en conexión como WCF estarán más familiarizados con el modelo de comunicación de conexión.
Los hubs son pipelines de comunicación basados en API pero de mayor nivel que permiten a clientes y servidores llamar directamente a métodos entre sí. SignalR hace un trabajo excelente gestionando la planificación entre máquinas, permitiendo a los clientes llamar fácilmente a métodos en el servidor como si llamaran a métodos locales, y viceversa. Los desarrolladores que hayan utilizado AIPs basadas en llamadas remotas como .Net Remoting estarán más familiarizados con el modelo hub. Usando el hub, también puedes pasar parámetros fuertemente tipados a los métodos y vincularlos al modelo.
Diagrama arquitectónico: El diagrama siguiente muestra la relación entre el hub, la conexión continua y la tecnología subyacente utilizada para el transporte.
9. Cómo funciona el buje:
Cuando el código del servidor llama al cliente, este enviará un paquete que contiene el método y los parámetros que llaman (cuando el objeto se usa como parámetro de método, se serializará como JSON para ser enviado) al cliente. El cliente entonces comprueba el nombre del método recibido y realiza una búsqueda de coincidencia en el método definido por el cliente, y si la coincidencia tiene éxito, el método se ejecuta y el objeto deserializado se utiliza como parámetro del método.
Puedes usar herramientas como Fiddler para monitorizar la ejecución de llamadas a métodos. La siguiente imagen muestra un método capturado de los registros de Fiddler para enviarse desde el servidor SignalR al cliente del navegador web. El método iniciado desde el hub se llama MoveShapeHub, y el método llamado es updateShape.
En este ejemplo, el nombre del hub se identifica con el parámetro "H", el nombre del método con el parámetro "M" y el objeto del parámetro enviado al método se identifica con el parámetro "A". La aplicación que generó el mensaje se implementó en el tutorial de comunicación en tiempo real de alta frecuencia.
Elige un modelo de comunicación:
La mayoría de las aplicaciones utilizan la API del hub, que puede emplearse en las siguientes situaciones:
Necesitas especificar el formato en el que se envía el mensaje.
Los desarrolladores prefieren utilizar un modelo de mensajería y programación en lugar de un modelo de llamadas remotas
El modelo de mensajería se está utilizando en aplicaciones existentes y está previsto que sea portado a SignalR.
|
Publicado en 5/7/2017 10:21:40
|
|
|
|
Propietario