Introducción: SignalR en ASP.NET MVC

En la entrada anterior vimos de forma general cómo podemos realizar aplicaciones real-time en ASP.NET MVC. En este post nos vamos a centrar en el primero de esos puntos: SignalR.

Como ya vimos, SignalR nos permite gestionar todas aquellas funcionalidades en las cuales tenemos una interacción en dos vías (conexión bidireccional) entre el servidor y sus clientes.

ASP.NET SignalR es una librería para los desarrolladores de aplicaciones ASP.NET que simplifica el proceso de agregar funcionalidad basada en interacción web en tiempo real. Cuando hablamos de interacción web en tiempo real hacemos referencia a la capacidad de poder enviar contenido desde el servidor a determinadas aplicaciones clientes que lo tendrán disponible de forma inmediata, en vez de que el servidor tenga que esperar que el cliente le solicite nueva información. Esto permite lograr un esquema de conexión bidireccional completo.

Si nuestra aplicación ASP.NET tiene alguna interacción donde necesitamos tener comunicación bidireccional, y para ello utilizamos alguna técnica alternativa (como por ejemplo long polling), quiere decir que podemos usar SignalR en la misma.

 

Vamos a ver algunas cuestiones de teoría asociada a esta interacción en tiempo real entre cliente y servidor. Básicamente existen varias técnicas para poder lograr este comportamiento, algunas mejores en su planteamiento y otras que tienen una mayor compatibilidad:

  • HTTP Polling: es una técnica mediante la cual el cliente envía request’s HTTP sucesivos y de forma periódica al servidor, simulando de esa forma una conexión en tiempo real y esperando tener siempre la información actualizada. Esta técnica tiene el problema de que se realizan demasiadas conexiones al servidor, derivando en un mal aprovechamiento y desperdicio de recursos y ancho de banda.
  • HTTP Long Polling: es una variante de la técnica anterior. En la misma el cliente hace request’s HTTP sucesivos, pero el servidor no envía la respuesta de forma inmediata sino que deja la conexión abierta esperando a que haya alguna novedad que enviar o la conexión expire. Esta solución tiene como problema la mala utilización de conexiones abiertas en el servidor sin ninguna utilización, además de la gestión manual que debe hacerse para manejar conexiones interrumpidas por la espiración.
  • Forever Frame: esta técnica crea un elemento IFrame oculto, que realiza un request al server. El mismo indica en la respuesta que tiene un gran volumen de datos que enviar, por lo cual utiliza el encoding chunked. En el mismo se envía contenido constantemente de forma parcial, dándole la posibilidad al servidor de que en cierto momento pase la información que realmente necesita hacerle llegar a su cliente. La ventaja de esta alternativa es que el funcionamiento está soportado por el protocolo HTTP y es nativo, aunque nuevamente estaremos desperdiciando recursos.
  • WebSockets: es la solución nativa provista con el estándar HTML5 para establecer conexiones bidireccionales entre servidor y clientes. Esto permite que en cualquier momento ambas partes puedan comunicarse sin restricciones.
IntroSignalR - WebSocketsCompatibilidad
Compatibilidad actual de WebSockets

 

  • Server-Sent Events: al igual que WebSockets, es una nueva funcionalidad provista por el estándar HTML5. El objetivo de la misma es permitir la comunicación unidireccional desde el servidor al cliente.
IntroSignalR - ServerSideEventsCompatibilidad.jpg
Compatibilidad actual de Server-Sent Events

 

Con esta explicación claramente podemos afirmar que WebSockets es la mejor alternativa de implementación para comunicación bidireccional, en realidad es la única que nos lo ofrece de forma nativa. Pero no todo es color de rosa, ya que se nos presentan dos situaciones:

  • Compatibilidad en todos los navegadores: HTML5 ya es un estándar definido y en general todos los navegadores nuevos tienen gran compatibilidad con el mismo. Pero puede haber casos donde no sea así, y si en esos sólo utilizamos WebSockets dejaremos a esos clientes sin funcionalidad. Una alternativa más robusta sería validar si el cliente tiene compatibilidad con WebSockets, y si no fuera así ir por alguna de las otras alternativas como fallback.
  • Gestión manual de las conexiones: con la versión 4.5 del framework .NET ya tenemos soporte para gestionar conexiones mediante WebSockets. Aunque es algo menor, debemos realizar el desarrollo de esta interacción, además de las alternativas para cada uno de los fallback’s, ya que la conexión por WebSockets tiene sus particularidades. A su vez, nos quedará la gestión de la seguridad y rendimiento de nuestra solución real-time.

 

Ahora bien, con todo este contenido como marco introductorio podemos explicar y entender de forma más clara SignalR. Inicialmente mencionábamos que es una librería que nos permite que nuestras aplicaciones ASP.NET MVC puedan tener una interacción en tiempo real entre servidor y clientes. SignalR no nos provee de una nueva técnica, sino que se encarga de gestionar las anteriormente vistas de forma interna y trasparente, sin que nosotros debamos lidiar con cada una y sus implicancias. Además de darnos algunas soluciones generales para poder gestionar los clientes, crear grupos de los mismos y gestionar la comunicación con los mismos.

A modo general podemos establecer las siguientes ventajas del porqué usar SignalR en nuestras aplicaciones ASP.NET MVC:

  • Elección automática de la mejor alternativa de comunicación con cada cliente: dependiendo de las características de cada cliente elegirá la mejor alternativa de comunicación, pero que sea 100% funcional en el mismo. Podemos establecer en forma general el siguiente orden de prioridad en la elección:
    • WebSockets
    • Server-Sent Events
    • Forever Frame
    • HTTP Long Polling
  • Unicidad en el desarrollo: independientemente de que técnica sea la elegida, de nuestro lado no debemos hacer nada adicional desde el lado de desarrollo. Haremos el mismo de forma convencional siguiendo las directivas de SignalR, y la infraestructura del mismo se encargará de la adaptación a cada alternativa.
  • Utilización de una solución probada: SignalR es una solución usada y probada en general, además de contar con el soporte oficial de Microsoft. Ello implica que tiene resuelta distintas situaciones, cómo por ejemplo la seguridad y rendimiento. Además de contar con la documentación sobre cómo configurar esos distintos aspectos.

 

Componentes de SignalR

SignalR propone dos formas de comunicación entre cliente y servidor: Persistent Connections y Hubs.

Persistent Connections

Es la comunicación a más bajo nivel que propone esta API, representando una conexión entre el servidor y un cliente, grupo o broadcast.

Hubs

Un Hub es el punto de mayor nivel de esta API, armado sobre las Persistent Connections, permitiendo que tanto el servidor y cliente puedan llamarse entre sí. Es aquí donde está lo más interesante y útil de SignalR, ya que podremos realizar esas invocaciones de métodos de forma bidireccional, pasando como parámetros tipos simples y complejos de forma totalmente transparente.

IntroSignalR - Modelo
Ejemplo básico de uso de un Hub

 

Con esto cerramos la introducción a SignalR. En los próximos post’s iremos profundizando ya en los aspectos asociados a la implementación en nuestras aplicaciones ASP.NET MVC.

Mientras tanto les dejo del juego ShootR, provisto por el equipo de SignalR como una demostración de lo que se puede lograr.

Gracias por leer!

Anuncios

Un comentario en “Introducción: SignalR en ASP.NET MVC

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s