1. Vad är SignalR:
ASP.NET SignalR är ett bibliotek av klasser som tillhandahålls för att förenkla processen att lägga till levande webbinnehåll i applikationer av utvecklingsutvecklare. Realtidswebbfunktionalitet innebär att serverkod aktivt kan skicka innehåll till klienter när som helst, istället för att servern ska vänta på en begäran från klienten (innan innehållet returneras).
Alla "live" typer av webbfunktionalitet kan läggas till i din ASP.NET applikation med hjälp av SignalR. Det vanligaste exemplet är chattrum, men vi kan göra mycket mer än så. Tänk på följande situationer: användare behöver ständigt uppdatera webbsidan för att se den senaste datan; Eller hämta (och visa) ny data på sidan genom att implementera lång polling, då kan du överväga att använda SignalR för det. Till exempel: instrumentpaneler och övervakningsapplikationer; Samarbetsapplikationer (t.ex. flera personer som redigerar dokument samtidigt); Uppdateringar om jobbutveckling och presentationsformulär i realtid, etc.
SignalR är också lämpligt för nyare typer av webbapplikationer som kräver högfrekventa uppdateringar från servern, såsom realtidsspel. Här är ett bra exempel: ShoorR.
SignalR tillhandahåller ett enkelt API för användare att skapa server-till-klient fjärrproceduranrop (RPC) som enkelt kan nås från serversidan. Nätkod. SignalR inkluderar även anslutningar (t.ex. anslutnings- och frånkopplingshändelser) samt anslutningsgruppering.
SignalR kan automatiskt hantera anslutningar. Och låter dig skicka sändningsmeddelanden till alla anslutna klienter, precis som i ett chattrum. Självklart, utöver massutskick, kan du också skicka meddelanden till specifika kunder. Anslutningen mellan klient och server är beständig, till skillnad från det traditionella HTTP-protokollet, som kräver att anslutningen återupprättas för varje kommunikation.
SignalR stöder funktionen "server push", där serverkod kan anropa klientkod i webbläsaren genom att använda fjärrproceduranrop (RPC) istället för förfrågningar som för närvarande används på webben – den motsvarande bearbetningsmodellen.
SignalR-applikationer kan utökas till tusentals klienter med hjälp av Service Bus, SQL SERVER eller Redis.
SignalR är öppen källkod och kan nås via GitHub.
2. SignalR och WebSocket
ignalR använder WebSocket-transportmetoden – där det är möjligt. Och byter automatiskt till den gamla transportmetoden (t.ex. HTTP lång anslutning). Du kan absolut skriva din applikation direkt med WebSockets, men att använda SignalR innebär att du får mer extra funktionalitet utan att behöva uppfinna hjulet på nytt. Viktigast av allt är att du kan fokusera på affärsimplementeringen utan att behöva skapa kompatibel kod separat för den gamla klienten. SignalR gör det också möjligt att undvika att oroa dig för WebSocket-uppdateringar, eftersom SignalR fortsätter att uppdateras för att stödja ändringar av underliggande transportmetoder för att erbjuda ett konsekvent åtkomstgränssnitt för applikationer över olika versioner av WebSockets.
Självklart kan du skapa en lösning som bara använder WebSocket-transport, och SignalR tillhandahåller alla funktioner du kan behöva för att skriva egen kod, som att återgå till andra transportmetoder och modifiera din applikation för nyare WebSocket-implementationer.
3. Transport och återresa
SignalR är en abstraktion av transportteknologin som krävs för att implementera realtidsfunktioner mellan klienter och servrar. SignalR startar först anslutningen med HTTP och kontrollerar om WebSocket är tillgänglig – om ja, uppgradera till WebSockets anslutning. WebSocket är den mest idealiska överföringsmetoden för SignalR eftersom den utnyttjar serverminnet mest effektivt, har lägst latens och omfattande underliggande funktioner (såsom fulldubbelkommunikation mellan klient och server), men också har de striktaste kraven: servern måste använda operativsystemet Windows Server 2012 eller Windows 8, och samtidigt. .NET framework version 4.5 och senare. Om dessa krav inte uppfylls kommer SignalR att försöka använda en alternativ överföringsmetod för att ansluta anslutningen.
4. HTML5-frakt
Transportmetoden som används beror på om klientwebbläsaren stöder HTML5, annars kommer den gamla transportmetoden att användas.
WebSocket (om både servern och webbläsaren stödjer WebSocket). WebSocket är det enda sättet att etablera en verklig och hållbar tvåvägsanslutning på både klient- och serversidan. Självklart har WebSocket också de striktaste kraven: det stöds endast i de senaste versionerna av IE, Chrome och FF, och är endast delvis implementerat i andra webbläsare som Opera och Safari.
Servern skickar händelser, även kända som EventSource (om webbläsaren stödjer server-sändningshändelser stöder i princip alla webbläsare utom IE denna funktion).
5. Kometöverföring
Följande transporttyper baseras på Comet-webbapplikationsmodellen, där webbläsaren eller klienten upprätthåller en lång HTTP-anslutningsförfrågan, och servern kan skicka data till klienten utan en explicit begäran från klienten.
Forever Frame (endast IE) Forever Frame skapar en dold IFrame som skickar en förfrågan till servern som inte kommer att slutföras. Servern skickar sedan kontinuerligt skript till klienten och körs omedelbart av klienten, det vill säga en envägs realtidsanslutning från servern till klienten. Klient-till-server-anslutningen använder en annan anslutning än den anslutningen. Till exempel skapar en standard HTML-förfrågan en ny anslutning för varje data som skickas.
Ajax long polling skapar inte en persistent anslutning, utan pollar genom att ständigt göra förfrågningar till servern. Vänta på att servern svarar och stäng denna anslutning på varje anslutning, och gör sedan omedelbart en ny förfrågan. Självklart kommer detta att orsaka viss fördröjning när anslutningen återställs och återansluts.
För information om transportmetoder som stöds av olika konfigurationer, se Stödda plattformar. (Dvs. kräver 8 eller högre, andra webbläsare är den nuvarande versionen -1)
Processen för val av överföringsmetod
Följande lista visar hur SignalR bestämmer vilken typ som ska användas för överföring.
IE8 och tidigare, använd lång polling.
Om JSONP är konfigurerad (dvs. jsonp-parametern är satt till sann vid anslutning), använd long polling.
Om du använder en domänöverskridande anslutning (dvs. om SignalR-ändpunkten och sidan inte är i samma domän), använd då WebSockets om följande villkor är uppfyllda:
Klienten stöder Cross-Domain Resource Sharing (CORS), se CORS för detaljer
Klienten stöder WebSocket
Servern stöder WebSocket
Om något av ovanstående villkor inte uppfylls används en lång undersökning. För mer information om tvärdomänförbindelser, se Hur man etablerar tvärdomänförbindelser.
Om du inte konfigurerar användningen av JSONP och anslutningen inte är domänkryssande, använd WebSocket, förstås, förutsatt att både klienten och servern stöder WebSocket.
Om klienten eller servern inte stödjer WebSockets, använd servern för att skicka händelser.
Om servern skickar en händelse inte är tillgänglig, använd en Forever Frame.
Om Forever Frame inte är tillgänglig, använd lång omröstning.
Övervakningsöverföring
Du kan se vilken transportmetod din applikation använder genom att aktivera Hub-loggning och i webbläsarens konsol.
För att aktivera loggning, lägg till följande kommando i klientapplikationen:
nnection.hub.logging = true;
6. Inspektion och transport:
Du kan se vilken transportmetod din applikation använder genom att aktivera Hub-loggning och i webbläsarens konsol. För att aktivera loggning, lägg till följande kommando i klientapplikationen:
nnection.hub.logging = true;
$.connection.hub.logging = true;
I IE, tryck F12 för att öppna utvecklarverktygen och klicka på fliken Konsol.
I Chrome, tryck på Ctrl+Shift+J för att öppna konsolen
Genom att observera loggningen i konsolen kan du se vilken överföringsmetod SignalR använder.
7. Utpekad sjöfart:
Att förhandla om överföringsmetoden kräver en viss tid och serverns/klientens resurser. Om klientmiljön är känd kan transportmetoden specificeras när anslutningen initieras för att förbättra prestandan. Följande kod visar att Ajax långa polling används direkt vid anslutningsinitiering om klienten är känd för att stödja något annat protokoll:
connection.start({ transport: 'longPolling' });
Om du vill att en kund ska förhandla om transporten i en specifik ordning kan du specificera i vilken ordning förhandlingen ska försökas. Koden nedan visar hur man först kan prova att använda WebSockets och använda lång polling direkt efter misslyckande.
connection.start({ transport: ['webSockets','longPolling'] });
De strängkonstanter som användaren specificerar definieras enligt följande:
webSockets
forverFrame
serverSentEvents
långpollling
8. Anslutningar och hubbar SignalR API inkluderar två klient-server-kommunikationsmodeller: beständiga anslutningar och hubbar.
En anslutning representerar en enkel slutpunkt för att skicka ett enskilt, grupperat eller sänd meddelande. PersistentConnection API (representerat av klassen PersistentConnection i .NET-kod) ger utvecklare direkt tillgång till SignalR:s underliggande kommunikationsprotokoll. Utvecklare som har använt anslutningsbaserade API:er som WCF kommer att vara mer bekanta med anslutningskommunikationsmodellen.
Hubbar är API-baserade men högre nivå kommunikationspipelines som tillåter klienter och servrar att anropa metoder direkt till varandra. SignalR gör ett utmärkt jobb med att hantera schemaläggning över maskiner, vilket gör att klienter enkelt kan anropa metoder på servern som om de kallade lokala metoder, och vice versa. Utvecklare som har använt fjärranropsbaserade AIP:er som .Net Remoting kommer att vara mer bekanta med hubbmodellen. Med hubben kan du också skicka starkt typade parametrar till metoder och binda dem till modellen.
Arkitekturdiagram: Diagrammet nedan visar relationen mellan navet, den kontinuerliga anslutningen och den underliggande teknologin som används för transport.
9. Hur hubben fungerar:
När serverkoden anropar klienten skickar servern ett paket som innehåller den anropande metoden och parametrarna (när objektet används som metodparameter serialiseras det som JSON för att skickas) till klienten. Klienten kontrollerar sedan namnet på mottagen metod och utför en matchningsuppslagning i den klientdefinierade metoden, och om matchningen lyckas körs metoden och det deserialiserade objektet används som metodparameter.
Du kan använda verktyg som Fiddler för att övervaka metodanropskörningen. Följande bild visar en metod som fångats från Fiddlers loggar och ska skickas från SignalR-servern till webbläsarklienten. Metoden som initieras från hubben kallas MoveShapeHub, och metoden som heter updateShape.
I detta exempel identifieras hubbens namn med parametern "H", metodnamnet med parametern "M", och parameterobjektet som skickas till metoden identifieras med parametern "A". Applikationen som genererade meddelandet implementerades i högfrekvent realtidskommunikationshandledning.
Välj en kommunikationsmodell:
De flesta applikationer använder hubbens API, som kan användas i följande situationer:
Du behöver specificera formatet som meddelandet skickas i.
Utvecklare föredrar att använda en meddelande- och schemaläggningsmodell snarare än en fjärrsamtalsmodell
Meddelandemodellen används i befintliga applikationer och planeras att porteras till SignalR.
|
Publicerad på 2017-07-05 10:21:40
|
|
|
|
Hyresvärd