1. Hvad er SignalR:
ASP.NET SignalR er et bibliotek af klasser, der er til rådighed for at forenkle processen med at tilføje live webindhold til applikationer af udviklingsudviklere. Real-time webfunktionalitet refererer til at tillade serverkode aktivt at sende indhold til klienterne når som helst, i stedet for at serveren venter på en anmodning fra klienten (før indholdet returneres).
Alle "live" former for webfunktionalitet kan tilføjes til din ASP.NET-applikation ved hjælp af SignalR. Det mest brugte eksempel er chatrum, men vi kan gøre meget mere end det. Overvej følgende situationer: brugere skal konstant opdatere websiden for at se de nyeste data; Eller hent (og vis) nye data på siden ved at implementere lang afstemning, så kan du overveje at bruge SignalR til det. For eksempel: dashboards og overvågningsapplikationer; Samarbejdsapplikationer (f.eks. flere personer, der redigerer dokumenter samtidig); Opdateringer om jobfremskridt og præsentationsformularer i realtid osv.
SignalR er også velegnet til nyere typer webapplikationer, der kræver højfrekvente opdateringer fra serveren, såsom realtidsspil. Her er et godt eksempel: ShoorR.
SignalR tilbyder et simpelt API, hvor brugere kan oprette server-til-klient fjernprocedurekald (RPC'er), som nemt kan tilgås fra serversiden. Netkode. SignalR inkluderer også forbindelser (f.eks. forbindelses- og afbrydelseshændelser) samt forbindelsesgruppering.
SignalR kan automatisk administrere forbindelser. Og lader dig sende broadcast-beskeder til alle tilsluttede klienter, ligesom i et chatrum. Selvfølgelig kan du, ud over masseudsendelse, også sende beskeder til specifikke kunder. Forbindelsen mellem klient og server er vedvarende, i modsætning til den traditionelle HTTP-protokol, som kræver, at forbindelsen genetableres for hver kommunikation.
SignalR understøtter "server push"-funktionen, hvor serverkode kan kalde klientkode i browseren ved hjælp af fjernprocedurekald (RPC) i stedet for anmodninger, der i øjeblikket almindeligvis bruges på nettet – den tilsvarende behandlingsmodel.
SignalR-applikationer kan udvides til tusindvis af klienter ved hjælp af Service Bus, SQL SERVER eller Redis.
SignalR er open source og kan tilgås via GitHub.
2. SignalR og WebSocket
ignalR bruger WebSocket-transportmetoden – hvor det er muligt. Og skifter automatisk til den gamle transportmetode (f.eks. HTTP lang forbindelse). Du kan selvfølgelig skrive din applikation direkte med WebSockets, men ved at bruge SignalR får du mere ekstra funktionalitet uden at skulle opfinde den dybe tallerken igen. Det vigtigste er, at du kan fokusere på forretningsimplementeringen uden at tænke på at skabe kompatibel kode separat til den gamle klient. SignalR gør det også muligt at undgå at skulle bekymre dig om WebSocket-opdateringer, da SignalR fortsat vil blive opdateret for at understøtte ændringer af underliggende transportmetoder for at give en ensartet adgangsgrænseflade for applikationer på tværs af forskellige versioner af WebSockets.
Selvfølgelig kan du skabe en løsning, der kun bruger WebSocket-transport, og SignalR leverer alle de funktioner, du måtte have brug for for at skrive din egen kode, såsom at falde tilbage på andre transportmetoder og tilpasse din applikation til nyere WebSocket-implementeringer.
3. Transport og hjemkomst
SignalR er en abstraktion af den transportteknologi, der kræves for at implementere realtidsfunktioner mellem klienter og servere. SignalR starter først forbindelsen med HTTP og tjekker, om WebSocket er tilgængelig – hvis ja, opgrader til WebSocket-forbindelsen. WebSocket er den mest ideelle transmissionsmetode for SignalR, fordi den udnytter serverhukommelsen mest effektivt, har den laveste latenstid og omfattende underliggende funktioner (såsom fuld-duplex kommunikation mellem klient og server), men også har de strengeste krav: serveren skal bruge Windows Server 2012 eller Windows 8 operativsystem, og samtidig. .NET framework version 4.5 og nyere. Hvis disse krav ikke opfyldes, vil SignalR forsøge at bruge en alternativ transmissionsmetode til at forbinde.
4. HTML5-forsendelse
Den anvendte transportmetode afhænger af, om klientbrowseren understøtter HTML5, ellers vil den gamle transportmetode blive brugt.
WebSocket (hvis både serveren og browseren understøtter WebSocket). WebSocket er den eneste måde at etablere en ægte og holdbar tovejsforbindelse både på klient- og serversiden. Selvfølgelig har WebSocket også de strengeste krav: det understøttes kun i de nyeste versioner af IE, Chrome og FF, og er kun delvist implementeret i andre browsere som Opera og Safari.
Serveren sender events, også kendt som EventSource (hvis browseren understøtter server-udsendelsesevents, understøtter stort set alle browsere undtagen IE denne funktion).
5. Komettransmission
Følgende transporttyper er baseret på Comet webapplikationsmodellen, hvor browseren eller klienten opretholder en lang HTTP-forbindelsesanmodning, og serveren kan sende data til klienten uden en eksplicit anmodning fra klienten.
Forever Frame (altså kun Forever Frame) Forever Frame vil oprette en skjult IFrame, der sender en anmodning til serveren, som ikke bliver fuldført. Serveren sender derefter løbende scripts til klienten, som udføres straks af klienten, dvs. en envejs realtidsforbindelse fra serveren til klienten. Klient-til-server-forbindelsen bruger en anden forbindelse end den forbindelse. For eksempel opretter en standard HTML-anmodning en ny forbindelse for hver data, der sendes.
Ajax long polling skaber ikke en vedvarende forbindelse, men poller ved konstant at sende anmodninger til serveren. Vent på, at serveren svarer, og luk denne forbindelse på hver forbindelse, og lav derefter straks en ny anmodning. Selvfølgelig vil dette forårsage en vis forsinkelse, når forbindelsen nulstilles og genoprettes.
For information om transportmetoder, der understøttes af forskellige konfigurationer, se Understøttede platforme. (dvs. kræver 8 eller højere, andre browsere er den nuværende version -1)
Overførselsmetodevalgsproces
Følgende liste viser, hvordan SignalR beslutter, hvilken type der skal bruges til transmission.
IE8 og tidligere, brug long polling.
Hvis JSONP er konfigureret (dvs. at jsonp-parameteren sættes til true ved forbindelse), brug long polling.
Hvis du bruger en krydsdomæneforbindelse (dvs. at SignalR-endepunktet og siden ikke er i samme domæne), så brug WebSockets, hvis følgende betingelser er opfyldt:
Klienten understøtter Cross-Domain Resource Sharing (CORS), se CORS for detaljer
Klienten understøtter WebSocket
Serveren understøtter WebSocket
Hvis nogen af ovenstående betingelser ikke er opfyldt, anvendes en lang poll. For mere information om krydsdomæneforbindelser, se Sådan etablerer du krydsdomæneforbindelser.
Hvis du ikke konfigurerer brugen af JSONP, og forbindelsen ikke er på tværs af domæner, så brug selvfølgelig WebSocket, forudsat at både klienten og serveren understøtter WebSocket.
Hvis klienten eller serveren ikke understøtter WebSockets, brug serveren til at sende events.
Hvis serveren sender en begivenhed, der ikke er tilgængelig, brug en Forever Frame.
Hvis Forever Frame ikke er tilgængelig, brug lang afstemning.
Overvågning af transmission
Du kan se, hvilken transportmetode din applikation bruger, ved at aktivere Hub-logging og i din browsers konsol.
For at aktivere logning tilføjes følgende kommando til klientapplikationen:
nnection.hub.logging = sand;
6. Inspektion og transport:
Du kan se, hvilken transportmetode din applikation bruger, ved at aktivere Hub-logging og i din browsers konsol. For at aktivere logning tilføjes følgende kommando til klientapplikationen:
nnection.hub.logging = sand;
$.connection.hub.logging = sand;
I IE skal du trykke F12 for at åbne udviklerværktøjerne og klikke på fanen Console.
I Chrome skal du trykke Ctrl+Shift+J for at åbne konsollen
Ved at observere loggningen i konsollen kan du se den transmissionsmetode, som SignalR bruger.
7. Udpeget skibsfart:
Forhandling af transmissionsmetoden kræver en vis mængde tid og serverens/klientens ressourcer. Hvis klientmiljøet er kendt, kan transportmetoden specificeres, når forbindelsen initieres, for at forbedre ydeevnen. Følgende kode demonstrerer brugen af Ajax' lange polling direkte ved forbindelsesstart, hvis klienten er kendt for at understøtte en anden protokol:
connection.start({ transport: 'longPolling' });
Hvis du vil have en klient til at forhandle transporten i en bestemt rækkefølge, kan du specificere rækkefølgen, hvor forhandlingen forsøges. Koden nedenfor viser, hvordan man prøver at bruge WebSockets først og bruger long polling direkte efter fejl.
connection.start({ transport: ['webSockets','longPolling'] });
De strengkonstanter, som brugeren specificerer, defineres som følger:
webSockets
forverFrame
serverSentEvents
LongPolling
8. Forbindelser og hubs SignalR API'en inkluderer to klient-server kommunikationsmodeller: vedvarende forbindelser og hubs.
En forbindelse repræsenterer et simpelt endepunkt til at sende en enkelt, grupperet eller broadcast-besked. PersistentConnection API'et (repræsenteret af PersistentConnection-klassen i .NET-kode) giver udviklere direkte adgang til SignalR's underliggende kommunikationsprotokol. Udviklere, der har brugt forbindelsesbaserede API'er som WCF, vil være mere fortrolige med forbindelseskommunikationsmodellen.
Hubs er API-baserede, men højere niveau kommunikationspipelines, der tillader klienter og servere at kalde metoder direkte til hinanden. SignalR gør et fremragende stykke arbejde med at håndtere tværmaskineplanlægning, så klienter nemt kan kalde metoder på serveren, som om de kaldte lokale metoder, og omvendt. Udviklere, der har brugt fjernopkaldsbaserede AIP'er som .Net Remote, vil være mere fortrolige med hub-modellen. Ved hjælp af hubben kan du også sende stærkt typede parametre til metoder og binde dem til modellen.
Arkitekturdiagram: Diagrammet nedenfor viser forholdet mellem knudepunktet, den kontinuerlige forbindelse og den underliggende teknologi, der bruges til transport.
9. Sådan fungerer hubben:
Når serverkoden kalder klienten, sender serveren en pakke, der indeholder den kaldende metode og parametre (når objektet bruges som metodeparameter, vil det blive serialiseret som JSON til at blive sendt) til klienten. Clienten tjekker derefter navnet på den modtagne metode og udfører et match-opslag i den klientdefinerede metode, og hvis matchet lykkes, udføres metoden, og det deserialiserede objekt bruges som metodeparameter.
Du kan bruge værktøjer som Fiddler til at overvåge udførelsen af metodekald. Det følgende billede viser en metode, der er optaget fra Fiddlers logs, som sendes fra SignalR-serveren til webbrowserens klient. Metoden, der initieres fra hubben, kaldes MoveShapeHub, og metoden hedder updateShape.
I dette eksempel identificeres hubbens navn med parameteren "H", metodenavnet med parameteren "M", og parameterobjektet, der sendes til metoden, identificeres med parameteren "A". Applikationen, der genererede beskeden, blev implementeret i den højfrekvente realtidskommunikationsvejledning.
Vælg en kommunikationsmodel:
De fleste applikationer bruger hubbens API, som kan bruges i følgende situationer:
Du skal angive formatet, som beskeden sendes i.
Udviklere foretrækker at bruge en besked- og planlægningsmodel frem for en fjernopkaldsmodel
Beskedmodellen anvendes i eksisterende applikationer og planlægges porteret til SignalR.
|
Opslået på 05/07/2017 10.21.40
|
|
|
|
Udlejer