Creación de una aplicación en tiempo real con SignalR: parte 2

Esta publicación es la continuación de mi publicación anterior donde discutimos las necesidades, los conceptos básicos, las configuraciones y el mecanismo de transporte de SignalR. En esta publicación, daremos un paso más allá al crear una aplicación de muestra y analizarla más a fondo.

A grandes rasgos, esta publicación se puede dividir en dos partes principales: en la primera parte, crearemos una muestra y en la otra, veremos cómo funciona SignalR en varios entornos y analizaremos la solicitud de comunicación entre el cliente y el servidor.

Trabajando en la muestra

La monitorización del servidor es una de las tareas importantes que realizamos varias veces en diversos escenarios. Una forma sencilla de hacerlo es a través del inicio de sesión remoto en el servidor para monitorear, o también puede usar un cliente que conecte el servidor, extraiga los contadores de rendimiento necesarios y muestre esa información en consecuencia.

En este ejemplo vamos a crear una aplicación de monitoreo de servidor que mostrará la utilización de los recursos del servidor en tiempo real. Nuestro ejemplo será básico, ya que nuestro objetivo es explicar SignalR, y leeremos algunos contadores básicos del servidor y mostraremos esa información en la interfaz de usuario. La interfaz de usuario se actualizará cada segundo, lo que se implementa a través de un temporizador en el servidor que envía los datos al cliente cada segundo.

Ya hemos visto la configuración requerida en nuestra publicación anterior, por lo que creé una aplicación de ASP.NET vacía y completé los siguientes pasos:

• Paquete Nuget de SignalR instalado
• Se agregó la clase de inicio y se agregó el método de configuración
• Se agregó un archivo HTML como Index.HTML y se agregaron jQuery, jQuery SignalR y Hub proxy.

La parte principal de cualquier aplicación de SignalR es el HUB. Hay dos cosas clave que vamos a hacer aquí. En primer lugar, leer el contador de recursos del servidor y, en segundo lugar, enviar esta información a los clientes conectados después de un cierto intervalo (en este ejemplo, 1 segundo). Así que veamos la implementación del hub:

[HubMethodName("sendSeverDetails")]
public void SendSeverDetails()
{
	string processorTime;
	string memoryUsage;
	string diskReadperSec;
	string diskWriteperSec;
	string diskTransferperSec;

	// Getting the server counters
	GetServerUsageDetails(out processorTime, out memoryUsage, out
		diskReadperSec, out diskWriteperSec, out diskTransferperSec);

	// Broadcasting the counters to the connected clients
	Clients.All.SendSeverDetails(processorTime, memoryUsage,
		diskReadperSec, diskWriteperSec, diskTransferperSec, DateTime.Now.ToString());
}

Este es el método central del concentrador. Aquí obtenemos los contadores del servidor y luego llamamos a la función de devolución de llamada del cliente y pasamos todos los parámetros. En este ejemplo, estamos pasando diferentes parámetros para cada valor de contador, pero también podemos crear una instancia y pasar una cadena JSON. Como necesitamos seguir actualizando el cliente con el último contador, necesitamos llamar a este método en ciertos intervalos (aquí digamos 1 segundo). Esto se puede lograr a través de un temporizador como tal:

static Timer myTimer;

private readonly TimeSpan _updateInterval = TimeSpan.FromMilliseconds(1000);

public ServerDetailsHub()
{
	myTimer = new System.Threading.Timer(UpdateUI, null, _updateInterval, _updateInterval); 
	// Rest of the code removed for brevity. Download the solution for complete code
}

// This is called via Timer after certain interval which inturn calls the core hub method
private void UpdateUI(object state)
{
	SendSeverDetails();
}

Ahora veamos nuestro lado del cliente, donde hemos definido el método de devolución de llamada.

$(function () {
    var num = 1;
    // Declare a proxy to reference the hub.
    var hubProxy = $.connection.serverDetailsHub;
    // Create a function that the hub can call to broadcast messages.
    hubProxy.client.sendSeverDetails = function (processorTime, memoryUsage, diskReadperSec, diskWriteperSec, diskTransferperSec, when) {
        $('#tblServerUsage tr').last().after("<tr><td>" + num++ + "</td><td>" + processorTime + "</td><td>" + memoryUsage + "</td><td>"
            + diskReadperSec + "</td><td>" + diskWriteperSec + "</td><td>" + diskTransferperSec + "</td><td>" + when + "</td></tr>");               
    };
 
    // Start the connection.
    $.connection.hub.start();
});

Nota: puede descargar el código completo de este ejemploaquí.

En el código anterior, hay tres cosas que estamos haciendo. En primer lugar, crear el proxy del concentrador; En segundo lugar, definimos el método de devolución de llamada que se llama desde el servidor y toma el mismo número de parámetros; y tercero, que es otro paso muy importante, poner en marcha el centro. Estos pasos realizan la negociación con el servidor y crean una conexión persistente con el servidor. En esta demostración, solo estoy agregando una nueva fila cada vez que se reciben los nuevos datos del servidor.

Análisis de la aplicación

SignalR crea un JavaScript de proxy en tiempo de ejecución que se usa para crear la instancia de proxy y establecer la conexión desde el servidor. Se puede ver si navegamos por la URL del proxy de la siguiente manera:

En mi publicación anterior, discutimos que SignalR es capaz de usar múltiples mecanismos de transporte y, según el escenario, elige una de las mejores opciones. Así que veamos cómo se da la negociación antes de seleccionar uno.

El tráfico anterior se captura mientras se ejecuta el ejemplo en IE 11. Después de descargar los scripts necesarios, descarga los hubs (que es el proxy que discutimos anteriormente). A continuación, verás el área rodeada en rojo por donde envía la solicitud de negociación al servidor. En función de eso, en la siguiente solicitud, se selecciona el transporte webSockets. También hay algunos otros datos con la solicitud, como el token de conexión, que es único por cliente.

Observemos en la misma aplicación en un entorno diferente:

Estos detalles se capturaron en Chrome, y aquí vemos que, aparte de las solicitudes comunes, envía la solicitud de negociación y elige serverSentEevents como transporte e inicia la solicitud utilizando el transporte seleccionado. Veamos un escenario más:

A través de IE9, recibimos tres solicitudes similares a las anteriores, excepto que el transporte seleccionado fue foreverFrame, que inicia la conexión.

Vemos que, en función de la solicitud de negociación, SignalR elige una de las mejores opciones y, a excepción de Web Socket, requiere una solicitud más para iniciar la conexión.

Limitación de los protocolos de transporte

SignalR es muy flexible y permite muchas opciones de configuración en función de las necesidades. Podemos configurar para un transporte específico o incluso podemos proporcionar el respaldo en un orden específico. Esto también ayuda a reducir el período de tiempo inicial para iniciar la conexión, ya que SignalR ya sabe qué protocolo de transporte se va a usar. Podemos proporcionar cualquier transporte específico mientras iniciamos el hub porque es la función que decide la selección del protocolo.

$.connection.hub.start({ transport: 'foreverFrame' });

Proporcionamos también las opciones de respaldo como

$.connection.hub.start({ transport: ['foreverFrame', 'longPolling'] });

Nota: Similar a $.connection.hub.start(), el proxy también proporciona otra función para detener la conexión persistente como $.connection.hub.stop() y una vez que se llama, necesitamos iniciar el hub nuevamente para continuar la comunicación entre el cliente y el servidor.

Conclusión

En esta publicación, hemos creado un ejemplo de monitor de servidor, donde el servidor envía los detalles del contador de uso del servidor en un cierto intervalo a todos los clientes conectados. Usamos un temporizador que después de un cierto intervalo genera un evento, que primero recopila los contadores y transmite al cliente conectado.

También examinamos las herramientas de desarrollo para examinar varios protocolos de transporte utilizados en varios escenarios y vimos que la misma aplicación usa diferentes protocolos en función de las negociaciones. También vimos cómo reducir el transporte o incluso proporcionar un protocolo específico, lo que reduce la sobrecarga inicial.

Espero que hayas disfrutado de este post, ¡y gracias por leer!