Introdução ao SignalR

por Patrick Fletcher

Este artigo descreve o que é o SignalR e algumas das soluções que ele foi projetado para criar.

Perguntas e comentários

Deixe comentários sobre como você gostou deste tutorial e o que poderíamos melhorar nos comentários na parte inferior da página. Se você tiver perguntas que não estejam diretamente relacionadas ao tutorial, você poderá postá-las no fórum do ASP.NET SignalR ou StackOverflow.com.

O que é o SignalR?

ASP.NET SignalR é uma biblioteca para desenvolvedores ASP.NET que simplifica o processo de adição de funcionalidade da Web em tempo real aos aplicativos. A funcionalidade da Web em tempo real é a capacidade de fazer com que o código do servidor envie conteúdo por push para clientes conectados instantaneamente à medida que ele se torna disponível, em vez de fazer com que o servidor aguarde um cliente solicitar novos dados.

O SignalR pode ser usado para adicionar qualquer tipo de funcionalidade da Web em tempo real ao seu aplicativo ASP.NET. Embora o chat seja frequentemente usado como exemplo, você pode fazer muito mais. Sempre que um usuário atualiza uma página da Web para ver novos dados ou a página implementa sondagem longa para recuperar novos dados, ele é um candidato para usar o SignalR. Os exemplos incluem painéis e aplicativos de monitoramento, aplicativos colaborativos (como edição simultânea de documentos), atualizações de progresso do trabalho e formulários em tempo real.

O SignalR também permite tipos completamente novos de aplicativos Web que exigem atualizações de alta frequência do servidor, por exemplo, jogos em tempo real.

O SignalR fornece uma API simples para criar chamadas de procedimento remoto (RPC) de servidor para cliente, que invocam funções JavaScript em navegadores de clientes (e outras plataformas de cliente) a partir do código .NET no lado do servidor. O SignalR também inclui a API para gerenciamento de conexões (por exemplo, conectar e desconectar eventos) e agrupar conexões.

O SignalR manipula o gerenciamento de conexões automaticamente e permite que você transmita mensagens para todos os clientes conectados simultaneamente, como uma sala de chat. Você também pode enviar mensagens para clientes específicos. A conexão entre o cliente e o servidor é persistente, ao contrário de uma conexão HTTP clássica, que é restabelecida para cada comunicação.

O SignalR oferece suporte à funcionalidade de "envio de dados pelo servidor", na qual o código do servidor pode chamar o código do cliente no navegador usando RPC (Remote Procedure Calls - Chamadas de Procedimento Remoto), em vez do modelo de solicitação-resposta que é comum na web atualmente.

Os aplicativos SignalR podem ser expandidos para milhares de clientes usando provedores de expansão internos e de terceiros.

Os provedores internos incluem:

• Barramento de Serviço
• SQL Server
• Redis

Provedores de terceiros incluem:

• NCache.

O SignalR é de software livre, acessível por meio do GitHub.

SignalR e WebSocket

O SignalR usa o novo transporte WebSocket quando disponível e recorre a transportes mais antigos, quando necessário. Embora você certamente possa escrever seu aplicativo usando WebSocket diretamente, usar o SignalR significa que grande parte da funcionalidade extra que você precisaria implementar já está feita para você. Mais importante, isso significa que você pode codificar seu aplicativo para aproveitar o WebSocket sem precisar se preocupar em criar um caminho de código separado para clientes mais antigos. O SignalR também protege você de ter que se preocupar com atualizações para o WebSocket, já que o SignalR é atualizado para dar suporte a alterações no transporte subjacente, fornecendo ao seu aplicativo uma interface consistente entre versões do WebSocket.

Transportes e alternativas

O SignalR é uma abstração sobre alguns dos transportes necessários para operações em tempo real entre o cliente e o servidor. O SignalR primeiro tenta estabelecer uma conexão WebSocket, se possível. WebSocket é o transporte ideal para o SignalR porque ele tem:

• O uso mais eficiente da memória do servidor.
• A latência mais baixa.
• Os recursos mais subjacentes, como comunicação duplex completa entre cliente e servidor.
• Os requisitos mais rigorosos, WebSocket, exigem o servidor:
  • Execute no Windows Server 2012 ou Windows 8.
  • .NET Framework 4.5.

Se esses requisitos não forem atendidos, o SignalR tentará usar outros transportes para fazer suas conexões.

Transporte HTML 5

Esses transportes dependem do suporte para HTML 5. Se o navegador cliente não der suporte ao padrão HTML 5, os transportes mais antigos serão usados.

• WebSocket (se o servidor e o navegador indicarem que podem dar suporte ao Websocket). WebSocket é o único transporte que estabelece uma verdadeira conexão bidirecional persistente entre o cliente e o servidor. No entanto, o WebSocket também tem os requisitos mais rigorosos; ele só tem suporte nas versões mais recentes do Microsoft Internet Explorer, Google Chrome e Mozilla Firefox e tem apenas uma implementação parcial em outros navegadores, como Opera e Safari.
• Eventos enviados pelo servidor, também conhecidos como EventSource (se o navegador der suporte a eventos enviados pelo servidor, que são basicamente todos os navegadores, exceto o Internet Explorer).)

Transportes de cometas

Os transportes a seguir são baseados no modelo de aplicativo Web Comet , no qual um navegador ou outro cliente mantém uma solicitação HTTP de longa duração, que o servidor pode usar para enviar dados por push para o cliente sem que o cliente solicite especificamente.

• Forever Frame (somente para Internet Explorer). O Forever Frame cria um IFrame oculto que faz uma solicitação para um endpoint no servidor que nunca se conclui. Em seguida, o servidor envia continuamente o script para o cliente que é executado imediatamente, fornecendo uma conexão unidirecional em tempo real do servidor para o cliente. A conexão de cliente para servidor usa uma conexão separada do servidor com a conexão do cliente e, como uma solicitação HTTP padrão, uma nova conexão é criada para cada parte dos dados que precisam ser enviados.
• Sondagem longa do Ajax. A sondagem longa não cria uma conexão persistente, mas sonda o servidor com uma solicitação que permanece aberta até que o servidor responda, momento em que a conexão é fechada e uma nova conexão é solicitada imediatamente. Isso pode introduzir um pouco de latência enquanto a conexão é redefinida.

Para obter mais informações sobre quais transportes têm suporte em quais configurações, consulte Plataformas compatíveis.

Processo de seleção de transporte

A lista a seguir mostra as etapas que o SignalR usa para decidir qual transporte usar.

1. Se o navegador for Internet Explorer 8 ou anterior, Long Polling será usado.

2. Se JSONP estiver configurado (ou seja, o jsonp parâmetro será definido para true quando a conexão for iniciada), a Sondagem Longa será usada.

3. Se uma conexão entre domínios estiver sendo feita (ou seja, se o ponto de extremidade do SignalR não estiver no mesmo domínio que a página de hospedagem), o WebSocket será usado se os seguintes critérios forem atendidos:

   • O cliente dá suporte a CORS (Compartilhamento de Recursos entre Origens). Para obter detalhes sobre quais clientes dão suporte ao CORS, consulte CORS em caniuse.com.

   • O cliente dá suporte ao WebSocket

   • O servidor dá suporte a WebSocket

     Se qualquer um desses critérios não for atendido, o Long Polling será utilizado. Para obter mais informações sobre conexões entre domínios, consulte Como estabelecer uma conexão entre domínios.

4. Se o JSONP não estiver configurado e a conexão não for entre domínios, o WebSocket será usado se o cliente e o servidor derem suporte a ele.

5. Se o cliente ou o servidor não der suporte ao WebSocket, os Eventos Enviados pelo Servidor serão usados se estiverem disponíveis.

6. Se Server Sent Events não estiver disponível, uma tentativa de usar o Forever Frame será feita.

7. Se "Forever Frame" falhar, "Long Polling" será usado.

Monitoramento de transportes

Você pode determinar qual transporte que seu aplicativo está utilizando ativando o registro de logs no hub e abrindo a janela do console no navegador.

Para habilitar o registro em log para eventos do hub em um navegador, adicione o seguinte comando ao aplicativo cliente:

$.connection.hub.logging = true;

• No Internet Explorer, abra as ferramentas de desenvolvedor pressionando F12 e clique na guia Console.

  

• No Chrome, abra o console pressionando Ctrl+Shift+J.

  

Com o console aberto e o log habilitado, você poderá ver qual transporte está sendo usado pelo SignalR.

Especificando um transporte

A negociação de um transporte leva um certo tempo e recursos de cliente/servidor. Se os recursos do cliente forem conhecidos, um transporte poderá ser especificado quando a conexão do cliente for iniciada. O snippet de código a seguir demonstra como iniciar uma conexão usando o transporte de Sondagem Longa do Ajax, como seria usado se soubesse que o cliente não dá suporte a nenhum outro protocolo:

connection.start({ transport: 'longPolling' });

Você pode especificar uma ordem de fallback se quiser que um cliente experimente transportes específicos em ordem. O trecho de código a seguir demonstra a tentativa de utilizar WebSocket, e caso isso falhe, ir diretamente para Long Polling.

connection.start({ transport: ['webSockets','longPolling'] });

As constantes de cadeia de caracteres para especificar transportes são definidas da seguinte maneira:

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Conexões e Hubs

A API do SignalR contém dois modelos para comunicação entre clientes e servidores: Conexões e Hubs Persistentes.

Uma Conexão representa um ponto de extremidade simples para enviar mensagens de destinatário único, agrupadas ou transmitidas. A API de Conexão Persistente (representada no código .NET pela classe PersistentConnection) fornece ao desenvolvedor acesso direto ao protocolo de comunicação de baixo nível que o SignalR expõe. O modelo de comunicação Connections será familiar para desenvolvedores que usaram APIs baseadas em conexão, como o Windows Communication Foundation.

Um Hub é um pipeline de nível mais alto criado com base na API de Conexão que permite que seu cliente e servidor chamem métodos entre si diretamente. O SignalR lida com a comunicação entre limites de máquinas como por mágica, permitindo que os clientes chamem métodos no servidor tão facilmente quanto métodos locais, e vice-versa. O uso do modelo de comunicação dos Hubs será familiar para os desenvolvedores que usaram APIs de invocação remota, como a Comunicação Remota do .NET. O uso de um Hub também permite que você passe parâmetros fortemente tipados para métodos, permitindo a associação de modelo.

Diagrama de arquitetura

O diagrama a seguir mostra a relação entre Hubs, Conexões Persistentes e as tecnologias subjacentes usadas para transportes.

Como os Hubs funcionam

Quando o código do lado do servidor chama um método no cliente, um pacote é enviado pelo transporte ativo que contém o nome e os parâmetros do método a ser chamado (quando um objeto é enviado como um parâmetro de método, ele é serializado usando JSON). Em seguida, o cliente faz a correspondência do nome do método aos métodos definidos no código do lado do cliente. Se houver uma correspondência, o método cliente será executado usando os dados de parâmetro desserializados.

A chamada de método pode ser monitorada usando ferramentas como o Fiddler. A imagem a seguir mostra uma chamada de método enviada de um servidor SignalR para um cliente do navegador da Web no painel Logs do Fiddler. A chamada de método está sendo enviada de um hub chamado MoveShapeHube o método que está sendo invocado é chamado updateShape.

Neste exemplo, o nome do hub é identificado com o H parâmetro; o nome do método é identificado com o M parâmetro e os dados enviados para o método são identificados com o A parâmetro. O aplicativo que gerou essa mensagem é criado no tutorial High-Frequency Realtime .

Escolhendo um modelo de comunicação

A maioria dos aplicativos deve usar a API de Hubs. A API de Conexões pode ser usada nas seguintes circunstâncias:

• O formato da mensagem real enviada precisa ser especificado.
• O desenvolvedor prefere trabalhar com um modelo de mensagens e expedição em vez de um modelo de invocação remota.
• Um aplicativo existente que usa um modelo de mensagens está sendo portado para usar o SignalR.