1. O que é o SignalR:
ASP.NET SignalR é uma biblioteca de classes fornecida para simplificar o processo de adição de conteúdo web ao vivo a aplicações por desenvolvedores de desenvolvimento. Funcionalidade web em tempo real refere-se a permitir que o código do servidor envie conteúdo ativamente para os clientes a qualquer momento, em vez de fazer o servidor esperar uma solicitação do cliente (antes de retornar o conteúdo).
Todos os tipos de funcionalidades web "ao vivo" podem ser adicionadas ao seu aplicativo ASP.NET usando o SignalR. O exemplo mais comum são as salas de bate-papo, mas podemos fazer muito mais do que isso. Considere as seguintes situações: os usuários precisam atualizar constantemente a página da web para ver os dados mais recentes; Ou recuperar (e exibir) novos dados na página implementando longas pesquisas, então você pode considerar usar o SignalR para isso. Por exemplo: dashboards e aplicativos de monitoramento; Aplicações colaborativas (por exemplo, várias pessoas editando documentos ao mesmo tempo); Atualizações de progresso do trabalho e formulários de apresentação em tempo real, etc.
O SignalR também é adequado para tipos mais recentes de aplicações web que exigem atualizações de alta frequência do servidor, como jogos em tempo real. Aqui vai um bom exemplo: ShoorR.
O SignalR oferece uma API simples para que os usuários criem chamadas remotas de procedimento (RPCs) entre servidor e cliente, que podem ser facilmente acessadas do lado do servidor. Código de rede. O SignalR também inclui conexões (por exemplo, eventos de conexão e desconexão) e agrupamento de conexão.
O SignalR pode gerenciar conexões automaticamente. E permite enviar mensagens transmitidas para todos os clientes conectados, assim como uma sala de bate-papo. Claro, além do envio em massa, você também pode enviar mensagens para clientes específicos. A conexão entre o cliente e o servidor é persistente, diferente do protocolo HTTP tradicional, que exige restabelecer a conexão para cada comunicação.
O SignalR suporta o recurso "server push", onde o código do servidor pode chamar o código do cliente no navegador usando chamadas de procedimento remoto (RPC) em vez de requisições atualmente comumente usadas na web – o modelo de processamento correspondente.
Aplicações SignalR podem ser estendidas para milhares de clientes usando Service Bus, SQL SERVER ou Redis.
O SignalR é de código aberto e pode ser acessado via GitHub.
2. SignalR e WebSocket
ignalR utiliza o método de transporte WebSocket - sempre que possível. E mudar automaticamente para o método de transporte antigo (por exemplo, conexão HTTP longa). Você certamente pode escrever sua aplicação diretamente com WebSockets, mas usar o SignalR significa que terá mais funcionalidades extras sem precisar reinventar a roda. Mais importante ainda, você pode focar na implementação do negócio sem pensar em criar código compatível separadamente para o cliente antigo. O SignalR também permite evitar a preocupação com atualizações do WebSocket, já que o SignalR continuará sendo atualizado para suportar mudanças nos métodos de transporte subjacentes para fornecer uma interface de acesso consistente para aplicações em diferentes versões do WebSockets.
Claro, você pode criar uma solução que use apenas transporte WebSocket, e o SignalR oferece todos os recursos que você pode precisar para escrever seu próprio código, como recorrer a outros métodos de transporte e modificar sua aplicação para implementações mais recentes do WebSocket.
3. Transporte e retorno
SignalR é uma abstração da tecnologia de transporte necessária para implementar funções em tempo real entre clientes e servidores. O SignalR inicia a conexão com HTTP e verifica se o WebSocket está disponível – se sim, atualize para a conexão do WebSocket. O WebSocket é o método de transmissão mais ideal para o SignalR porque faz uso mais eficiente da memória do servidor, possui a menor latência e funções subjacentes abrangentes (como comunicação full-duplex entre cliente e servidor), mas também possui os requisitos mais rigorosos: o servidor deve usar o sistema operacional Windows Server 2012 ou Windows 8, e ao mesmo tempo. .NET framework versão 4.5 e superior. Se esses requisitos não forem atendidos, o SignalR tentará usar um método alternativo de transmissão para se conectar.
4. Envio em HTML5
O método de transporte utilizado depende se o navegador cliente suporta HTML5, caso contrário, o método antigo será utilizado.
WebSocket (se tanto o servidor quanto o navegador suportarem WebSocket). O WebSocket é a única forma de estabelecer uma conexão verdadeira e duradoura bidirecional tanto do lado cliente quanto do servidor. Claro, o WebSocket também possui os requisitos mais rigorosos: ele é suportado apenas nas versões mais recentes do IE, Chrome e FF, e é implementado apenas parcialmente em outros navegadores como Opera e Safari.
O servidor envia eventos, também conhecidos como EventSource (se o navegador suportar eventos de envio de servidor, basicamente todos os navegadores, exceto o IE, suportam esse recurso).
5. Transmissão por cometa
Os seguintes tipos de transporte são baseados no modelo de aplicação web Comet, onde o navegador ou cliente manterá uma longa solicitação de conexão HTTP, e o servidor pode enviar dados para o cliente sem uma solicitação explícita do cliente.
Forever Frame (ou seja, apenas) Forever Frame criará um IFrame oculto que envia uma solicitação para o servidor que não será concluída. O servidor então envia scripts continuamente para o cliente e é executado imediatamente pelo cliente, ou seja, uma conexão unidirecional em tempo real do servidor para o cliente. A conexão cliente-servidor usa uma conexão diferente dessa conexão. Por exemplo, uma requisição HTML padrão cria uma nova conexão para cada dado enviado.
O polling longo do Ajax não cria uma conexão persistente, mas sim faz polling fazendo constantemente requisições ao servidor. Espere o servidor responder e feche essa conexão em cada conexão, e então faça uma nova solicitação imediatamente. Claro, isso vai causar algum atraso quando a conexão for reiniciada e reconectada.
Para informações sobre os métodos de transporte suportados por várias configurações, veja Plataformas Suportadas. (IE requer 8 ou mais, outros navegadores são a versão atual -1)
Processo de seleção do método de transferência
A lista a seguir mostra como o SignalR decide qual tipo usar para transmissão.
IE8 e anteriores, use longa polling.
Se o JSONP estiver configurado (ou seja, o parâmetro jsonp estiver definido como true ao conectar), use polling longo.
Se você estiver usando uma conexão multidomínio (ou seja, o endpoint do SignalR e a página não estiverem no mesmo domínio), então use WebSockets se as seguintes condições forem atendidas:
O cliente suporta o Compartilhamento de Recursos entre Domínios (CORS), veja CORS em para detalhes
O cliente suporta WebSocket
O servidor suporta WebSocket
Se alguma das condições acima não for atendida, é usada uma polte longa. Para mais informações sobre conexões entre domínios, veja Como estabelecer conexões entre domínios.
Se você não configurar o uso do JSONP e a conexão não for multidomínio, use WebSocket, claro, desde que tanto o cliente quanto o servidor suportem WebSocket.
Se o cliente ou servidor não suportar WebSockets, use o servidor para enviar eventos.
Se o servidor enviar um evento não estiver disponível, use um Forever Frame.
Se o Forever Frame não estiver disponível, use a longa polling.
Transmissão do monitor
Você pode ver qual método de transporte seu aplicativo usa ativando o logging do Hub e no console do seu navegador.
Para habilitar o registro, adicione o seguinte comando à aplicação cliente:
nnection.hub.logging = verdadeiro;
6. Inspeção e transporte:
Você pode ver qual método de transporte seu aplicativo usa ativando o logging do Hub e no console do seu navegador. Para habilitar o registro, adicione o seguinte comando à aplicação cliente:
nnection.hub.logging = verdadeiro;
$.conexão.hub.logging = verdadeiro;
No IE, pressione F12 para abrir as ferramentas de desenvolvimento e clique na aba Console.
No Chrome, pressione Ctrl+Shift+J para abrir o console
Ao observar o login no console, você pode ver o método de transmissão que o SignalR está usando.
7. Transporte Designado:
Negociar o método de transmissão requer um certo tempo e os recursos do servidor/cliente. Se o ambiente cliente for conhecido, então o método de transporte pode ser especificado quando a conexão é iniciada para melhorar o desempenho. O código a seguir demonstra o uso do long polling do Ajax diretamente na iniciação da conexão se o cliente for conhecido por suportar qualquer outro protocolo:
conexão.começar({ transporte: 'longPolling' });
Se você quiser que um cliente negocie o transporte em uma ordem específica, pode especificar a ordem em que a negociação é tentada. O código abaixo mostra como tentar usar WebSockets primeiro e usar longas pesquisas logo após a falha.
conexão.start({ transporte: ['webSockets','longPolling'] });
As constantes de cadeia especificadas pelo usuário são definidas da seguinte forma:
WebSockets
forverFrame
EventosEnviados do Servidor
longPolling
8. Conexões e Hubs A API do SignalR inclui dois modelos de comunicação cliente-servidor: conexões persistentes e hubs.
Uma conexão representa um ponto final simples para enviar uma única mensagem, agrupada ou transmitida. A API PersistentConnection (representada pela classe PersistentConnection no código .NET) oferece aos desenvolvedores acesso direto ao protocolo de comunicação subjacente do SignalR. Desenvolvedores que já usaram APIs baseadas em conexão, como o WCF, estarão mais familiarizados com o modelo de comunicação de conexão.
Hubs são pipelines de comunicação baseados em API, mas de nível mais alto, que permitem que clientes e servidores chamem métodos diretamente entre si. O SignalR faz um trabalho excelente ao lidar com o agendamento entre máquinas, permitindo que os clientes chamem facilmente métodos no servidor como se estivessem chamando métodos locais, e vice-versa. Desenvolvedores que já usaram AIPs baseadas em chamadas remotas, como o .Net Remoting, estarão mais familiarizados com o modelo de hub. Usando o hub, você também pode passar parâmetros fortemente tipados para métodos e vinculá-los ao modelo.
Diagrama de arquitetura: O diagrama abaixo mostra a relação entre o hub, a conexão contínua e a tecnologia subjacente usada para transporte.
9. Como o hub funciona:
Quando o código do servidor chama o cliente, o servidor envia um pacote contendo o método e os parâmetros de chamada (quando o objeto é usado como parâmetro de método, ele será serializado como JSON para ser enviado) para o cliente. O cliente então verifica o nome do método recebido e realiza uma busca de correspondência no método definido pelo cliente, e se a correspondência for bem-sucedida, o método é executado e o objeto desserializado é usado como parâmetro do método.
Você pode usar ferramentas como o Fiddler para monitorar a execução da chamada de método. A imagem a seguir mostra um método capturado dos logs do Fiddler para ser enviado do servidor SignalR ao cliente do navegador web. O método iniciado a partir do hub se chama MoveShapeHub, e o método chamado é updateShape.
Neste exemplo, o nome do hub é identificado com o parâmetro "H", o nome do método é identificado com o parâmetro "M" e o objeto do parâmetro enviado ao método é identificado com o parâmetro "A". O aplicativo que gerou a mensagem foi implementado no tutorial de comunicação em tempo real de alta frequência.
Escolha um modelo de comunicação:
A maioria das aplicações utiliza a API do hub, que pode ser usada nas seguintes situações:
Você precisa especificar o formato em que a mensagem é enviada.
Os desenvolvedores preferem usar um modelo de mensagens e agendamento em vez de um modelo de chamada remota
O modelo de mensagens está sendo usado em aplicações existentes e está planejado para ser portado para o SignalR.
|
Publicado em 05/07/2017 10:21:40
|
|
|
|
Senhorio