1. Kaj je SignalR:
ASP.NET SignalR je knjižnica tečajev, ki jih razvijalci uporabljajo za poenostavitev procesa dodajanja vsebin v živo v aplikacije. Funkcionalnost spleta v realnem času pomeni omogočanje, da strežniška koda kadarkoli aktivno pošilja vsebino odjemalcem, namesto da bi strežnik čakal na zahtevo odjemalca (preden vrne vsebino).
Vse "žive" vrste spletnih funkcionalnosti lahko dodate v svojo ASP.NET aplikacijo s pomočjo SignalR. Najpogosteje uporabljen primer so klepetalnice, vendar lahko naredimo še veliko več kot to. Razmislite o naslednjih situacijah: uporabniki morajo nenehno osveževati spletno stran, da vidijo najnovejše podatke; Ali pa pridobiš (in prikažeš) nove podatke na strani z uvedbo dolgega anketiranja, nato pa lahko razmisliš o uporabi SignalR. Na primer: nadzorne plošče in aplikacije za spremljanje; sodelovalne aplikacije (npr. več ljudi, ki hkrati urejajo dokumente); Posodobitve napredka pri delu in obrazci za predstavitve v realnem času itd.
SignalR je primeren tudi za novejše vrste spletnih aplikacij, ki zahtevajo pogoste posodobitve s strežnika, kot je igranje v realnem času. Tukaj je dober primer: ShoorR.
SignalR zagotavlja preprost API, ki uporabnikom omogoča ustvarjanje strežnik-to-client oddaljenih klicih postopkov (RPC), do katerih je mogoče enostavno dostopati s strežniške strani. Spletna koda. SignalR vključuje tudi povezave (npr. dogodke povezave in prekinitve) ter združevanje povezav.
SignalR lahko samodejno upravlja povezave. In omogoča pošiljanje oddajnih sporočil vsem povezanim odjemalcem, podobno kot klepetalnica. Seveda lahko poleg množičnega pošiljanja pošiljate tudi sporočila določenim strankam. Povezava med odjemalcem in strežnikom je trajna, za razliko od tradicionalnega HTTP protokola, ki zahteva ponovno vzpostavitev povezave za vsako komunikacijo.
SignalR podpira funkcijo "potisk strežnika", kjer strežniška koda lahko kliče odjemalsko kodo v brskalniku z uporabo oddaljenih postopkovnih klicev (RPC) namesto zahtev, ki so trenutno pogosto uporabljene na spletu – ustreznega modela obdelave.
SignalR aplikacije je mogoče razširiti na tisoče odjemalcev z uporabo Service Bus, SQL SERVER ali Redis.
SignalR je odprtokoden in dostopen prek GitHuba.
2. SignalR in WebSocket
ignalR uporablja metodo prenosa WebSocket – kjer je mogoče. In samodejno preklopi na staro metodo prenosa (npr. HTTP dolga povezava). Seveda lahko svojo aplikacijo napišete neposredno z WebSockets, vendar uporaba SignalR pomeni, da boste imeli več dodatnih funkcionalnosti, ne da bi morali izumljati kolo na novo. Najpomembneje je, da se lahko osredotočite na poslovno implementacijo, ne da bi razmišljali o ustvarjanju združljive kode ločeno za starega odjemalca. SignalR vam prav tako omogoča, da se izognete skrbi za posodobitve WebSocketa, saj se bo SignalR še naprej posodabljal, da bo podpiral spreminjajoče se osnovne metode prenosa in zagotavljal dosleden dostopni vmesnik za aplikacije v različnih različicah WebSockets.
Seveda lahko ustvarite rešitev, ki uporablja samo WebSocket transport, SignalR pa ponuja vse funkcije, ki jih morda potrebujete za pisanje lastne kode, kot so vračanje k drugim transportnim metodam in prilagajanje aplikacije za novejše WebSocket implementacije.
3. Prevoz in vrnitev
SignalR je abstrakcija transportne tehnologije, potrebne za implementacijo funkcij v realnem času med odjemalci in strežniki. SignalR najprej vzpostavi povezavo s HTTP in preveri, ali je WebSocket na voljo – če je mogoče, nadgradi na WebSocketovo povezavo. WebSocket je najbolj idealna metoda prenosa za SignalR, ker najbolj učinkovito izkorišča strežniški pomnilnik, ima najnižjo zakasnitev in obsežne osnovne funkcije (kot je polno-dupleksna komunikacija med odjemalcem in strežnikom), hkrati pa ima najstrožje zahteve: strežnik mora hkrati uporabljati operacijski sistem Windows Server 2012 ali Windows 8. .NET framework različica 4.5 in novejša. Če ti pogoji niso izpolnjeni, bo SignalR poskušal uporabiti alternativno metodo prenosa za povezavo.
4. Pošiljanje v HTML5
Uporabljeni način prenosa je odvisen od tega, ali brskalnik podpira HTML5, sicer bo uporabljen stari način prenosa.
WebSocket (če strežnik in brskalnik podpirata WebSocket). WebSocket je edini način za vzpostavitev prave in trajne dvosmerne povezave tako na strani odjemalca kot strežnika. Seveda ima WebSocket tudi najstrožje zahteve: podprt je le v najnovejših različicah IE, Chrome in FF, v drugih brskalnikih, kot sta Opera in Safari, pa je le delno implementiran.
Strežnik pošilja dogodke, znane tudi kot EventSource (če brskalnik podpira dogodke pošiljanja strežnika, praktično vsi brskalniki razen IE podpirajo to funkcijo).
5. Prenos s kometom
Naslednje vrste prenosa temeljijo na modelu spletne aplikacije Comet, kjer brskalnik ali odjemalec vzdržuje dolgo HTTP zahtevo za povezavo, strežnik pa lahko podatke pošilja odjemalcu brez izrecne zahteve odjemalca.
Forever Frame (samo IE) Forever Frame ustvari skriti IFrame, ki strežniku pošlje zahtevo, ki ne bo dokončana. Strežnik nato neprekinjeno pošilja skripte odjemalcu, ki jih odjemalec takoj izvede, torej enosmerna povezava v realnem času med strežnikom in odjemalcem. Povezava med odjemalcem in strežnikom uporablja drugačno povezavo kot ta povezava. Na primer, standardna HTML zahteva ustvari novo povezavo za vsak poslani podatek.
Ajax dolgo anketiranje ne ustvarja trajne povezave, temveč anketiranje z nenehnim pošiljanjem zahtevkov strežniku. Počakajte, da strežnik odgovori, zaprete to povezavo pri vsaki povezavi in takoj oddajte novo zahtevo. Seveda bo to povzročilo nekaj zamika pri ponastavitvi in ponovni povezavi povezave.
Za informacije o transportnih metodah, ki jih podpirajo različne konfiguracije, glejte Podprte platforme. (IE zahteva 8 ali več, drugi brskalniki imajo trenutno različico -1)
Postopek izbire metode prenosa
Naslednji seznam prikazuje, kako SignalR odloča, katero vrsto uporabiti za oddajanje.
IE8 in starejši uporabljajo dolge ankete.
Če je JSONP konfiguriran (tj. parameter jsonp je ob povezavi nastavljen na resnično), uporabite dolgo polling.
Če uporabljate povezavo med domenami (tj. SignalR končna točka in stran nista v isti domeni), uporabite WebSockets, če so izpolnjeni naslednji pogoji:
Odjemalec podpira izmenjavo virov med domenami (CORS), podrobnosti glejte CORS na
Odjemalec podpira WebSocket
Strežnik podpira WebSocket
Če kateri od zgoraj navedenih pogojev ni izpolnjen, se uporabi dolga anketa. Za več informacij o meddomenskih povezavah glejte Kako vzpostaviti meddomenske povezave.
Če ne konfigurirate uporabe JSONP in povezava ni meddomenska, seveda uporabite WebSocket, če podpirata WebSocket tako odjemalec kot strežnik.
Če odjemalec ali strežnik ne podpira WebSockets, uporabite strežnik za pošiljanje dogodkov.
Če strežnik pošlje dogodek ni na voljo, uporabite Forever Frame.
Če Forever Frame ni na voljo, uporabite dolgo anketiranje.
Spremljanje prenosa
Način, ki ga uporablja vaša aplikacija, lahko vidite, če omogočite Hub logging in v konzoli brskalnika.
Za omogočanje beleženja dodajte naslednji ukaz v odjemalsko aplikacijo:
nnection.hub.logging = res;
6. Pregled in prevoz:
Način, ki ga uporablja vaša aplikacija, lahko vidite, če omogočite Hub logging in v konzoli brskalnika. Za omogočanje beleženja dodajte naslednji ukaz v odjemalsko aplikacijo:
nnection.hub.logging = res;
$.connection.hub.logging = res;
V IE pritisnite F12, da odprete orodja za razvijalce, in kliknite na zavihek Konzola.
V Chromu pritisnite Ctrl+Shift+J, da odprete konzolo
Z opazovanjem beleženja v konzoli lahko vidite način prenosa, ki ga uporablja SignalR.
7. Določena ladja:
Pogajanje o načinu prenosa zahteva določen čas in vire strežnika/odjemalca. Če je okolje odjemalca znano, je mogoče ob vzpostavitvi povezave določiti način prenosa za izboljšanje zmogljivosti. Naslednja koda prikazuje uporabo Ajaxovega dolgega anketiranja neposredno ob začetku povezave, če je znano, da odjemalec podpira kakšen drug protokol:
connection.start({ transport: 'longPolling' });
Če želite, da stranka pogaja o prevozu v določenem vrstnem redu, lahko določite vrstni red, v katerem se pogajanja izvajajo. Spodnja koda prikazuje, kako najprej poskusiti uporabiti WebSockets in po neuspehu uporabiti dolgo anketiranje.
connection.start({ transport: ['webSockets','longPolling'] });
Nizne konstante, ki jih uporabnik določi, so definirane takole:
webSockets
forverFrame
serverSentEvents
longPolling
8. Povezave in vozlišča API SignalR vključuje dva modela komunikacije med odjemalcem in strežnikom: trajne povezave in vozlišča.
Povezava predstavlja preprosto končno točko za pošiljanje enojnega, združenega ali oddajnega sporočila. API PersistentConnection (predstavljen kot razred PersistentConnection v .NET kodi) razvijalcem omogoča neposreden dostop do osnovnega komunikacijskega protokola SignalR. Razvijalci, ki so uporabljali API-je, ki temeljijo na povezavah, kot je WCF, bodo bolje seznanjeni z modelom komunikacije povezav.
Vozlišča so API-jevi, a višje nivojski komunikacijski cevovodi, ki omogočajo odjemalcem in strežnikom, da si med seboj neposredno kličejo metode. SignalR odlično obvladuje razporejanje med računalniki, saj odjemalcem omogoča enostavno klicanje metod na strežniku, kot da kličejo lokalne metode, in obratno. Razvijalci, ki so uporabljali AIP-je, ki temeljijo na oddaljenih klicih, kot je .Net Remonting, bodo bolj seznanjeni z modelom vozlišč. Z uporabo huba lahko tudi posredujete močno tipizirane parametre metodam in jih povežete z modelom.
Arhitekturni diagram: Spodnji diagram prikazuje razmerje med vozliščem, neprekinjeno povezavo in osnovno tehnologijo, uporabljeno za prevoz.
9. Kako deluje hub:
Ko strežniška koda kliče odjemalca, strežnik pošlje paket z metodo klica in parametri (ko se objekt uporablja kot parameter metode, se serializira kot JSON za pošiljanje) odjemalcu. Odjemalec nato preveri prejeto ime metode in izvede iskanje ujemanja v metodi, ki jo definira odjemalca, in če je ujemanje uspešno, se metoda izvede in deserializirani objekt se uporabi kot parameter metode.
Lahko uporabite orodja, kot je Fiddler, za spremljanje izvajanja klica metode. Naslednja slika prikazuje metodo, zajeto iz Fiddlerjevih dnevnikov, ki se pošlje s strežnika SignalR v odjemalca spletnega brskalnika. Metoda, ki se sproži iz huba, se imenuje MoveShapeHub, metoda pa updateShape.
V tem primeru je ime vozlišča povezano s parametrom "H", ime metode s parametrom "M", objekt parametra, poslan metodi, pa s parametrom "A". Aplikacija, ki je generirala sporočilo, je bila implementirana v tutorialu za visokofrekvenčno komunikacijo v realnem času.
Izberite komunikacijski model:
Večina aplikacij uporablja API huba, ki ga je mogoče uporabiti v naslednjih situacijah:
Morate navesti obliko, v kateri je sporočilo poslano.
Razvijalci raje uporabljajo model sporočanja in razporejanja kot model oddaljenih klicev
Model sporočanja se uporablja v obstoječih aplikacijah in je načrtovan prenos na SignalR.
|
Objavljeno na 5. 07. 2017 10:21:40
|
|
|
|
Najemodajalec