Introduzione a SignalR

di Patrick Fletcher

Questo articolo descrive cos'è SignalR e alcune delle soluzioni progettate per la creazione.

Domande e commenti

Lasciare commenti e suggerimenti su come è piaciuta questa esercitazione e cosa è possibile migliorare nei commenti nella parte inferiore della pagina. Se si hanno domande che non sono direttamente correlate all'esercitazione, è possibile pubblicarle nel forum di ASP.NET SignalR o StackOverflow.com.

Che cos'è SignalR?

ASP.NET SignalR è una libreria per sviluppatori ASP.NET che semplifica il processo di aggiunta di funzionalità Web in tempo reale alle applicazioni. La funzionalità Web in tempo reale è la possibilità di fare in modo che il contenuto push del codice del server ai client connessi diventi immediatamente disponibile, anziché attendere che un client richieda nuovi dati.

SignalR può essere usato per aggiungere qualsiasi tipo di funzionalità Web "in tempo reale" all'applicazione ASP.NET. Anche se la chat viene spesso usata come esempio, è possibile fare molto di più. Ogni volta che un utente aggiorna una pagina Web per visualizzare nuovi dati o la pagina implementa un polling lungo per recuperare nuovi dati, è un candidato per l'uso di SignalR. Tra gli esempi sono inclusi dashboard e applicazioni di monitoraggio, applicazioni collaborative (ad esempio la modifica simultanea dei documenti), aggiornamenti dello stato dei processi e moduli in tempo reale.

SignalR consente anche nuovi tipi di applicazioni Web che richiedono aggiornamenti ad alta frequenza dal server, ad esempio giochi in tempo reale.

SignalR offre una semplice API per la creazione di chiamate RPC (Server-to-Client Remote Procedure Call) che chiamano funzioni JavaScript nei browser client (e altre piattaforme client) dal codice .NET lato server. SignalR include anche l'API per la gestione delle connessioni (ad esempio, eventi di connessione e disconnessione) e il raggruppamento delle connessioni.

SignalR gestisce automaticamente la gestione delle connessioni e consente di trasmettere messaggi a tutti i client connessi contemporaneamente, come in una chat room. È anche possibile inviare messaggi a client specifici. La connessione tra client e server è persistente, a differenza di una connessione HTTP classica, che viene ristabilita per ogni comunicazione.

SignalR supporta la funzionalità "server push", in cui il codice del server può chiamare il codice client nel browser usando chiamate rpc (Remote Procedure Call), anziché il modello di richiesta-risposta comune sul Web.

Le applicazioni SignalR possono aumentare fino a migliaia di client usando provider predefiniti e di terze parti con scalabilità orizzontale.

I provider predefiniti includono:

• Bus di servizio
• SQL Server
• Redis

I provider di terze parti includono:

• NCache.

SignalR è open source, accessibile tramite GitHub.

SignalR e WebSocket

SignalR usa il nuovo trasporto WebSocket, dove disponibile ed esegue il fallback ai trasporti meno recenti, se necessario. Anche se è certamente possibile scrivere l'app usando Direttamente WebSocket, l'uso di SignalR significa che molte delle funzionalità aggiuntive che è necessario implementare sono già state eseguite automaticamente. Soprattutto, ciò significa che è possibile scrivere codice per l'app per sfruttare WebSocket senza doversi preoccupare di creare un percorso di codice separato per i client meno recenti. SignalR protegge anche dalla necessità di preoccuparsi degli aggiornamenti di WebSocket, poiché SignalR viene aggiornato per supportare le modifiche nel trasporto sottostante, fornendo all'applicazione un'interfaccia coerente tra le versioni di WebSocket.

Trasporti e fallback

SignalR è un'astrazione su alcuni trasporti necessari per eseguire operazioni in tempo reale tra client e server. SignalR tenta prima di tutto di stabilire una connessione WebSocket, se possibile. WebSocket è il trasporto ottimale per SignalR perché ha:

• Uso più efficiente della memoria del server.
• Latenza più bassa.
• Le funzionalità più sottostanti, ad esempio la comunicazione duplex completa tra client e server.
• I requisiti più rigorosi, WebSocket richiede il server:
  • Eseguire in Windows Server 2012 o Windows 8.
  • .NET Framework 4.5

Se questi requisiti non sono soddisfatti, SignalR tenta di utilizzare altri trasporti per stabilire le connessioni.

Trasporti HTML 5

Questi trasporti dipendono dal supporto per HTML 5. Se il browser client non supporta lo standard HTML 5, verranno usati i trasporti meno recenti.

• WebSocket (se sia il server che il browser indicano che possono supportare Websocket). WebSocket è l'unico trasporto che stabilisce una vera connessione permanente bidirezionale tra client e server. Tuttavia, WebSocket ha anche i requisiti più rigorosi; è completamente supportato solo nelle versioni più recenti di Microsoft Internet Explorer, Google Chrome e Mozilla Firefox e ha solo un'implementazione parziale in altri browser come Opera e Safari.
• Eventi inviati dal server, noto anche come EventSource (se il browser supporta eventi inviati dal server, che è fondamentalmente tutti i browser ad eccezione di Internet Explorer).

Trasporti di cometa

I trasporti seguenti si basano sul modello di applicazione Web Comet , in cui un browser o un altro client gestisce una richiesta HTTP a lungo termine, che il server può usare per eseguire il push dei dati al client senza che il client lo richieda in modo specifico.

• Forever Frame (solo per Internet Explorer). Forever Frame crea un IFrame nascosto che effettua una richiesta a un endpoint nel server che non viene completato. Il server invia quindi continuamente lo script al client che viene immediatamente eseguito, fornendo una connessione unidirezionale in tempo reale dal server al client. La connessione da client a server usa una connessione separata dal server alla connessione client e, come una richiesta HTTP standard, viene creata una nuova connessione per ogni parte di dati che deve essere inviata.
• Polling lungo Ajax. Il polling lungo non crea una connessione permanente, ma esegue invece il polling del server con una richiesta che rimane aperta fino a quando il server non risponde, a quel punto la connessione viene chiusa e viene richiesta immediatamente una nuova connessione. Ciò può introdurre una latenza durante la reimpostazione della connessione.

Per altre informazioni sui trasporti supportati in quali configurazioni, vedere Piattaforme supportate.

Processo di selezione del trasporto

L'elenco seguente mostra i passaggi usati da SignalR per decidere quale trasporto utilizzare.

1. Se il browser è Internet Explorer 8 o versioni precedenti, viene utilizzato il polling lungo.

2. Se JSONP è configurato , ovvero il jsonp parametro viene impostato su true quando viene avviata la connessione, viene usato il polling lungo.

3. Se viene stabilita una connessione tra domini, ovvero se l'endpoint SignalR non si trova nello stesso dominio della pagina di hosting, Verrà usato WebSocket se vengono soddisfatti i criteri seguenti:

   • Il client supporta CORS (condivisione di risorse tra le origini). Per informazioni dettagliate sui client che supportano CORS, vedere CORS all'caniuse.com.

   • Il client supporta WebSocket

   • Il server supporta WebSocket

     Se uno di questi criteri non viene soddisfatto, verrà utilizzato il polling lungo. Per altre informazioni sulle connessioni tra domini, vedere Come stabilire una connessione tra domini.

4. Se JSONP non è configurato e la connessione non è tra domini, WebSocket verrà usato se sia il client che il server lo supportano.

5. Se il client o il server non supportaNo WebSocket, gli eventi inviati dal server vengono usati se disponibili.

6. Se gli eventi inviati dal server non sono disponibili, viene eseguito un tentativo di Forever Frame.

7. Se Forever Frame ha esito negativo, viene usato il polling lungo.

Monitoraggio dei trasporti

È possibile determinare il trasporto usato dall'applicazione abilitando la registrazione nell'hub e aprendo la finestra della console nel browser.

Per abilitare la registrazione per gli eventi dell'hub in un browser, aggiungere il comando seguente all'applicazione client:

$.connection.hub.logging = true;

• In Internet Explorer aprire gli strumenti di sviluppo premendo F12 e fare clic sulla scheda Console.

  

• In Chrome aprire la console premendo CTRL+MAIUSC+J.

  

Con la console aperta e abilitata la registrazione, sarà possibile vedere quale trasporto viene usato da SignalR.

Specifica di un trasporto

La negoziazione di un trasporto richiede una certa quantità di tempo e risorse client/server. Se le funzionalità client sono note, è possibile specificare un trasporto all'avvio della connessione client. Il frammento di codice seguente illustra l'avvio di una connessione usando il trasporto Ajax Long Polling, come se fosse noto che il client non supporta alcun altro protocollo:

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

È possibile specificare un ordine di fallback se si desidera che un client tenti trasporti specifici in ordine. Il frammento di codice seguente illustra il tentativo di WebSocket e l'esito negativo, passando direttamente a Polling lungo.

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

Le costanti stringa per specificare i trasporti sono definite come segue:

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Connessioni e hub

L'API SignalR contiene due modelli per la comunicazione tra client e server: connessioni persistenti e hub.

Una connessione rappresenta un endpoint semplice per l'invio di messaggi a destinatario singolo, raggruppati o trasmessi. L'API Connessione persistente (rappresentata nel codice .NET dalla classe PersistentConnection) consente allo sviluppatore di accedere direttamente al protocollo di comunicazione di basso livello esposto da SignalR. L'uso del modello di comunicazione Connections sarà familiare agli sviluppatori che hanno usato API basate sulla connessione, ad esempio Windows Communication Foundation.

Un hub è una pipeline più generale basata sull'API di connessione che consente al client e al server di chiamare direttamente i metodi. SignalR gestisce l'invio attraverso i limiti del computer come se fosse magico, consentendo ai client di chiamare i metodi sul server con la stessa facilità dei metodi locali e viceversa. L'uso del modello di comunicazione Hubs avrà familiarità con gli sviluppatori che hanno usato API di chiamata remota, ad esempio .NET Remoting. L'uso di un hub consente anche di passare parametri fortemente tipizzato ai metodi, abilitando l'associazione di modelli.

Diagramma dell'architettura

Il diagramma seguente illustra la relazione tra Hub, Connessioni persistenti e le tecnologie sottostanti usate per i trasporti.

Funzionamento degli hub

Quando il codice lato server chiama un metodo sul client, un pacchetto viene inviato nel trasporto attivo che contiene il nome e i parametri del metodo da chiamare (quando un oggetto viene inviato come parametro del metodo, viene serializzato tramite JSON). Il client corrisponde quindi al nome del metodo ai metodi definiti nel codice lato client. Se esiste una corrispondenza, il metodo client verrà eseguito usando i dati dei parametri deserializzati.

La chiamata al metodo può essere monitorata usando strumenti come Fiddler. L'immagine seguente mostra una chiamata al metodo inviata da un server SignalR a un client del Web browser nel riquadro Log di Fiddler. La chiamata al metodo viene inviata da un hub denominato MoveShapeHube il metodo richiamato viene chiamato updateShape.

In questo esempio il nome dell'hub viene identificato con il H parametro . Il nome del metodo viene identificato con il M parametro e i dati inviati al metodo vengono identificati con il A parametro . L'applicazione che ha generato questo messaggio viene creata nell'esercitazione a frequenza elevata in tempo reale .

Scelta di un modello di comunicazione

La maggior parte delle applicazioni deve usare l'API Hubs. L'API Connections può essere usata nelle circostanze seguenti:

• È necessario specificare il formato del messaggio effettivo inviato.
• Lo sviluppatore preferisce lavorare con un modello di messaggistica e invio anziché con un modello di chiamata remota.
• Un'applicazione esistente che usa un modello di messaggistica viene confermata per l'uso di SignalR.