Introduzione a SignalR

di Patrick Fletcher

Questo articolo descrive che cos'è SignalR e alcune delle soluzioni che è stato progettato per la creazione.

Domande e commenti

Lasciare commenti e suggerimenti su come è piaciuta questa esercitazione e su cosa è possibile migliorare nei commenti nella parte inferiore della pagina. Se si hanno domande non direttamente correlate all'esercitazione, è possibile pubblicarle nel forum 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 server ai client connessi diventi immediatamente disponibile, invece di fare in modo che il server attenda 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. Ad esempio, dashboard e applicazioni di monitoraggio, applicazioni collaborative (ad esempio la modifica simultanea dei documenti), gli aggiornamenti dello stato dei processi e i 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 (Remote Procedure Call) da server a client 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 i messaggi a tutti i client connessi contemporaneamente, ad esempio una chat room. È anche possibile inviare messaggi a client specifici. La connessione tra il client e il 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 scalare fino a supportare migliaia di client utilizzando provider incorporati e di terze parti.

I fornitori 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 utilizza il nuovo trasporto WebSocket, dove disponibile, e in caso contrario passa 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 codificare l'app per sfruttare i vantaggi di 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 dei 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 full duplex tra client e server.
• I requisiti più rigorosi, WebSocket richiedono 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.

Metodi di trasporto 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).

Comet Transports

I trasporti seguenti sono basati sul modello di applicazione Web Comet , in cui un browser o un altro client gestisce una richiesta HTTP di lunga durata, 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 sul server che non viene completata. Il server invia quindi continuamente lo script al client che viene eseguito immediatamente, fornendo una connessione unidirezionale in tempo reale dal server al client. La connessione dal client al server usa una connessione separata dal server alla connessione client e, come una richiesta HTTP standard, viene creata una nuova connessione per ogni porzione di dati che deve essere inviata.
• Ajax long polling. Il polling lungo non crea una connessione persistente, 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 certa 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 illustra i passaggi usati da SignalR per decidere quale trasporto usare.

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

2. Se JSONP è configurato (ovvero, il jsonp parametro viene impostato su true quando viene avviata la connessione), viene usato Long Polling.

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

   • Il client supporta il CORS (Condivisione delle Risorse tra Origini). Per informazioni dettagliate sui client che supportano CORS, vedere CORS all'indirizzo caniuse.com.

   • Il client supporta WebSocket

   • Il server supporta WebSocket

     Se uno di questi criteri non viene soddisfatto, verrà utilizzato il Long Polling. 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 supporta WebSocket, gli eventi inviati dal server vengono usati se disponibili.

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

7. Se Forever Frame fallisce, viene usato il long polling.

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 la registrazione abilitata, 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 nell'ordine. Il frammento di codice seguente illustra il tentativo di WebSocket e l'esito negativo, passando direttamente a Long Polling.

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 di 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'utilizzo del modello di comunicazione Connessioni è familiare agli sviluppatori che hanno utilizzato API basate su connessioni, come ad esempio Windows Communication Foundation.

Un hub è una pipeline di livello 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 confini delle macchine come per magia, consentendo ai client di chiamare metodi sul server con la stessa facilità dei metodi locali e viceversa. L'utilizzo del modello di comunicazione Hubs sarà familiare agli sviluppatori che hanno utilizzato API di invocazione remota, come .NET Remoting. L'uso di un hub consente anche di passare parametri fortemente tipizzati ai metodi, abilitando il binding di modelli.

Diagramma dell'architettura

Il diagramma seguente illustra la relazione tra Hub, Connessioni permanenti 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 attraverso il trasporto attivo che contiene il nome e i parametri del metodo da chiamare (quando un oggetto viene inviato come parametro di metodo, viene serializzato tramite JSON). Quindi il client abbina il 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 High-Frequency Realtime .

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 portata a usare SignalR.