Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
martes, 8 de julio de 2014
SignalROtra de las novedades que acompañan a la versión 2.1 de SignalR, y que sin duda puede resultar interesante en muchos escenarios, es la capacidad de tener desde los hubs una pista sobre el motivo por el que se desconectó un cliente, cosa que hasta ahora no era posible utilizando las herramientas que nos proporcionaba el framework de forma directa.

En versiones previas de SignalR, cuando en un hub recibimos el evento OnDisconnected() en realidad no sabemos si este cierre ha sido “educado”, es decir, provocado explícitamente por el cliente como consecuencia de una acción, como puede ser que el usuario haya decidido salir de la aplicación, o bien se ha debido a un problema en el software o comunicaciones (imaginad, por ejemplo, que se cae la conexión a internet).

En SignalR 2.1, el método OnDisconnected() dispone ahora de una sobrecarga mediante la cual se nos indica si el lado cliente llamó al método stop() para cerrar la conexión, o bien la conexión simplemente se cortó de forma no esperada:
public class EchoHub : Hub
{
    [...]

    public override Task OnDisconnected(bool stopCalled)
    {
        if (stopCalled) 
        {
            return Clients.All.Message(
                      "The connection " + Context.ConnectionId 
                      + " closed gracefully the connection");
        }
        else
        {
            return Clients.All.Message("Connection closed " + Context.ConnectionId);
        }
    }
}
El hecho de que stopCalled  nos llegue con un valor true implica que se invocó al método stop() en el lado cliente, lo que significa que ha sido un cierre controlado por la aplicación. Por ejemplo, podríamos haber ejecutado el método expresamente desde el lado cliente o, en caso de clientes web, incluso podría tratarse de un cambio de página o el cierre del navegador, pues ambas acciones provocan la llamada a stop() de forma automática.

Sin embargo, cuando nos llega con un valor false indica que ha transcurrido el tiempo máximo de timeout para la conexión y que, por tanto, podemos asumir que ésta se ha cerrado de forma no controlada. Esto ocurre cuando se corta la conexión, o cuando el proceso cliente muere de forma inesperada (por ejemplo por un error fatal), sin dar oportunidad a que se ejecute el código de cierre.

Por último, al usar esta nueva característica, especial atención a entornos escalados horizontalmente mediante backplanes, pues el cliente podría haber sufrido una caída temporal y, en el proceso de reconexión, haber ido a parar a un servidor SignalR distinto (!).

Publicado en Variable not found.

Aún no hay comentarios, ¡sé el primero!