1. Cos'è SignalR:
ASP.NET SignalR è una libreria di classi fornita per semplificare il processo di aggiunta di contenuti web in tempo reale alle applicazioni da parte degli sviluppatori. La funzionalità web in tempo reale si riferisce al permettere al codice server di inviare attivamente contenuti ai client in qualsiasi momento, invece di far attendere al server una richiesta dal client (prima di restituire contenuti).
Tutti i tipi di funzionalità web "live" possono essere aggiunte alla tua applicazione ASP.NET usando SignalR. L'esempio più comunemente usato sono le chat room, ma possiamo fare molto di più. Consideriamo le seguenti situazioni: gli utenti devono aggiornare costantemente la pagina web per vedere i dati più recenti; Oppure recuperare (e visualizzare) nuovi dati sulla pagina implementando un long polling, poi puoi considerare di usare SignalR per farlo. Ad esempio: cruscotti e applicazioni di monitoraggio; Applicazioni collaborative (ad esempio, più persone che modificano i documenti contemporaneamente); Aggiornamenti sui progressi del lavoro e moduli di presentazione in tempo reale, ecc.
SignalR è anche adatto a nuovi tipi di applicazioni web che richiedono aggiornamenti ad alta frequenza dal server, come il gioco in tempo reale. Ecco un buon esempio: ShoorR.
SignalR fornisce un'API semplice per permettere agli utenti di creare chiamate di procedura remota (RPC) da server a client facilmente accessibili dal lato server. Codice di rete. SignalR include anche connessioni (ad esempio, eventi di connessione e disconnessione) e il raggruppamento delle connessioni.
SignalR può gestire automaticamente le connessioni. E ti permette di inviare messaggi broadcast a tutti i client connessi, proprio come una chat room. Ovviamente, oltre agli invii di massa, puoi anche inviare messaggi a clienti specifici. La connessione tra client e server è persistente, a differenza del protocollo HTTP tradizionale, che richiede di ristabilire la connessione per ogni comunicazione.
SignalR supporta la funzione "server push", in cui il codice server può chiamare il codice client nel browser utilizzando remote procedure calls (RPC) invece delle richieste attualmente comunemente usate sul web - il modello di elaborazione corrispondente.
Le applicazioni SignalR possono essere estese a migliaia di client utilizzando Service Bus, SQL SERVER o Redis.
SignalR è open-source e può essere consultato tramite GitHub.
2. SignalR e WebSocket
ignalR utilizza il metodo di trasporto WebSocket - dove possibile. E passare automaticamente al vecchio metodo di trasporto (ad esempio connessione HTTP lunga). Puoi certamente scrivere la tua applicazione direttamente con WebSockets, ma usare SignalR significa avere più funzionalità extra senza dover reinventare la ruota. La cosa più importante è che puoi concentrarti sull'implementazione aziendale senza pensare a creare codice compatibile separatamente per il vecchio client. SignalR consente inoltre di evitare di dover preoccuparsi degli aggiornamenti WebSocket, poiché SignalR continuerà ad essere aggiornato per supportare la modifica dei metodi di trasporto sottostanti e fornire un'interfaccia di accesso coerente per applicazioni tra diverse versioni di WebSocket.
Naturalmente, puoi creare una soluzione che utilizza solo il trasporto WebSocket, e SignalR fornisce tutte le funzionalità di cui potresti aver bisogno per scrivere il tuo codice, come tornare ad altri metodi di trasporto e modificare la tua applicazione per implementazioni WebSocket più recenti.
3. Trasporto e ritorno
SignalR è un'astrazione della tecnologia di trasporto necessaria per implementare funzioni in tempo reale tra client e server. SignalR avvia prima la connessione con HTTP e verifica se il WebSocket è disponibile - se sì, aggiorna alla connessione del WebSocket. WebSocket è il metodo di trasmissione più ideale per SignalR perché sfrutta al modo più efficiente la memoria del server, ha la latenza più bassa e funzioni di base complete (come la comunicazione full-duplex tra client e server), ma ha anche i requisiti più severi: il server deve utilizzare Windows Server 2012 o Windows 8, e allo stesso tempo. .NET Framework versione 4.5 e superiore. Se questi requisiti non vengono soddisfatti, SignalR cercherà di utilizzare un metodo di trasmissione alternativo per collegarsi.
4. Spedizione HTML5
Il metodo di trasporto utilizzato dipende dal fatto che il browser client supporti HTML5, altrimenti verrà utilizzato il vecchio metodo di trasporto.
WebSocket (se sia il server che il browser supportano WebSocket). WebSocket è l'unico modo per stabilire una vera e duratura connessione bidirezionale sia dal lato client che dal server. Naturalmente, WebSocket ha anche i requisiti più severi: è supportato solo nelle ultime versioni di IE, Chrome e FF, ed è implementato solo parzialmente in altri browser come Opera e Safari.
Il server invia eventi, noti anche come EventSource (se il browser supporta eventi di invio del server, praticamente tutti i browser tranne IE supportano questa funzione).
5. Trasmissione della cometa
I seguenti tipi di trasporto si basano sul modello di applicazione web Comet, in cui il browser o il client manterranno una lunga richiesta di connessione HTTP e il server può inviare dati al client senza una richiesta esplicita da parte del client.
Forever Frame (cioè solo) Forever Frame creerà un IFrame nascosto che invia una richiesta al server che non verrà completata. Il server invia quindi continuamente script al client ed è eseguito immediatamente dal client, cioè una connessione in tempo reale unidirezionale dal server al client. La connessione client-server utilizza una connessione diversa da quella connessione. Ad esempio, una richiesta HTML standard crea una nuova connessione per ogni dato inviato.
Il long polling Ajax non crea una connessione persistente, ma fa sondaggi effettuando costantemente richieste al server. Aspetta che il server risponda e chiudi questa connessione su ogni connessione, poi fai immediatamente una nuova richiesta. Ovviamente, questo causerà un certo ritardo quando la connessione verrà ripristinata e riconnessa.
Per informazioni sui metodi di trasporto supportati dalle varie configurazioni, vedi Piattaforme supportate. (IE richiede 8 o superiori, altri browser sono la versione attuale -1)
Processo di selezione del metodo di trasferimento
L'elenco seguente mostra come SignalR decide quale tipo utilizzare per la trasmissione.
IE8 e precedenti, usano il sondaggio lungo.
Se JSONP è configurato (cioè il parametro jsonp è impostato su true durante la connessione), usa il long polling.
Se stai usando una connessione cross-domain (cioè, l'endpoint SignalR e la pagina non sono nello stesso dominio), allora usa WebSockets se sono soddisfatte le seguenti condizioni:
Il client supporta la Condivisione delle Risorse Cross-Domain (CORS), vedi CORS a per i dettagli
Il client supporta WebSocket
Il server supporta WebSocket
Se una delle condizioni sopra non viene soddisfatta, si utilizza un sondaggio lungo. Per maggiori informazioni sulle connessioni cross-domain, vedi Come stabilire connessioni cross-domain.
Se non configuri l'uso di JSONP e la connessione non è cross-domain, usa WebSocket, ovviamente, a patto che sia il client che il server supportino WebSocket.
Se il client o il server non supportano WebSocket, usa il server per inviare eventi.
Se il server invia un evento non è disponibile, usa un Forever Frame.
Se Forever Frame non è disponibile, usa il long polling.
Trasmissione del monitor
Puoi vedere quale metodo di trasporto utilizza la tua applicazione abilitando il logging dell'Hub e nella console del browser.
Per abilitare il loging, aggiungi il seguente comando all'applicazione client:
nnection.hub.logging = vero;
6. Ispezione e trasporto:
Puoi vedere quale metodo di trasporto utilizza la tua applicazione abilitando il logging dell'Hub e nella console del browser. Per abilitare il loging, aggiungi il seguente comando all'applicazione client:
nnection.hub.logging = vero;
$.connection.hub.logging = vero;
In IE, premi F12 per aprire gli strumenti di sviluppo e clicca sulla scheda Console.
In Chrome, premi Ctrl+Shift+J per aprire la console
Osservando il logging nella console, puoi vedere il metodo di trasmissione che SignalR sta usando.
7. Navigazione designata:
Negoziare il metodo di trasmissione richiede un certo tempo e le risorse del server/client. Se l'ambiente client è noto, il metodo di trasporto può essere specificato quando viene avviata la connessione per migliorare le prestazioni. Il seguente codice dimostra l'uso del lungo polling di Ajax direttamente all'inizio della connessione se il client è noto per supportare qualsiasi altro protocollo:
connection.start({ trasporto: 'longPolling' });
Se vuoi che un cliente negozi il trasporto in un ordine specifico, puoi specificare l'ordine in cui viene tentata la negoziazione. Il codice qui sotto mostra come provare prima a usare WebSockets e usare il long polling direttamente dopo il fallimento.
connection.start({ trasporto: ['webSockets','longPolling'] });
Le costanti di stringa specificate dall'utente sono definite come segue:
WebSockets
forverFrame
serverSentEvents
longPolling
8. Connessioni e Hub L'API SignalR include due modelli di comunicazione client-server: connessioni persistenti e hub.
Una connessione rappresenta un punto finale semplice per inviare un singolo messaggio, raggruppato o broadcast. L'API PersistentConnection (rappresentata dalla classe PersistentConnection nel codice .NET) offre agli sviluppatori accesso diretto al protocollo di comunicazione sottostante di SignalR. Gli sviluppatori che hanno utilizzato API basate su connessione come WCF saranno più familiari con il modello di comunicazione di connessione.
Gli hub sono pipeline di comunicazione basati su API ma di livello superiore che permettono a client e server di chiamare metodi direttamente tra loro. SignalR fa un ottimo lavoro nel gestire la pianificazione tra macchine, permettendo ai client di chiamare facilmente i metodi sul server come se stessero chiamando metodi locali, e viceversa. Gli sviluppatori che hanno utilizzato AIP basate su chiamate remote come .Net Remoting saranno più familiari con il modello hub. Usando l'hub, puoi anche passare parametri fortemente tipizzati ai metodi e collegarli al modello.
Diagramma architettonico: Il diagramma sottostante mostra la relazione tra l'hub, la connessione continua e la tecnologia sottostante utilizzata per il trasporto.
9. Come funziona l'hub:
Quando il codice del server chiama il client, il server invia un pacchetto contenente il metodo chiamante e i parametri (quando l'oggetto viene usato come parametro del metodo, viene serializzato come JSON da inviare) al client. Il client quindi controlla il nome del metodo ricevuto ed esegue una ricerca di corrispondenza nel metodo definito dal client; se la corrispondenza ha successo, il metodo viene eseguito e l'oggetto deserializzato viene utilizzato come parametro del metodo.
Puoi usare strumenti come Fiddler per monitorare l'esecuzione delle chiamate di metodo. L'immagine seguente mostra un metodo catturato dai log di Fiddler per essere inviato dal server SignalR al client del browser web. Il metodo avviato dall'hub si chiama MoveShapeHub, e il metodo chiamato è updateShape.
In questo esempio, il nome dell'hub è identificato con il parametro "H", il nome del metodo è identificato con il parametro "M" e l'oggetto parametro inviato al metodo è identificato con il parametro "A". L'applicazione che generava il messaggio era implementata nel tutorial di comunicazione in tempo reale ad alta frequenza.
Scegli un modello di comunicazione:
La maggior parte delle applicazioni utilizza l'API dell'hub, che può essere utilizzata nelle seguenti situazioni:
Devi specificare il formato in cui il messaggio viene inviato.
Gli sviluppatori preferiscono utilizzare un modello di messaggistica e programmazione piuttosto che un modello di chiamata remota
Il modello di messaggistica viene utilizzato nelle applicazioni esistenti ed è previsto per essere portato su SignalR.
|
Pubblicato su 05/07/2017 10:21:40
|
|
|
|
Padrone di casa