1. Mikä on SignalR:
ASP.NET SignalR on luokkakirjasto, jonka tarkoituksena on yksinkertaistaa kehityskehittäjien live-verkkosisällön lisäämistä sovelluksiin. Reaaliaikainen verkkotoiminnallisuus tarkoittaa sitä, että palvelinkoodi voi aktiivisesti lähettää sisältöä asiakkaille milloin tahansa, sen sijaan että palvelin odottaisi pyynnön saapumista (ennen sisällön palauttamista).
Kaikki "live"-verkkotoiminnot voidaan lisätä ASP.NET-sovellukseesi SignalR:n avulla. Yleisin esimerkki ovat chat-huoneet, mutta voimme tehdä paljon muutakin. Ota huomioon seuraavat tilanteet: käyttäjien täytyy jatkuvasti päivittää verkkosivua nähdäkseen viimeisimmät tiedot; Tai hakea (ja näyttää) uutta dataa sivulla toteuttamalla pitkä kysely, jolloin voit harkita SignalR:n käyttöä siihen. Esimerkiksi: kojelaudat ja valvontasovellukset; Yhteistyösovellukset (esim. useat henkilöt muokkaamassa dokumentteja samanaikaisesti); Työn etenemispäivitykset ja reaaliaikaiset esityslomakkeet jne.
SignalR sopii myös uudempiin verkkosovelluksiin, jotka vaativat palvelimelta korkeataajuisia päivityksiä, kuten reaaliaikaiseen pelaamiseen. Tässä hyvä esimerkki: ShoorR.
SignalR tarjoaa käyttäjille yksinkertaisen API:n palvelimelta asiakkaalle etäproseduurikutsujen (RPC) luomiseen, joihin pääsee helposti käsiksi palvelinpuolelta. Nettikoodi. SignalR sisältää myös yhteydet (esim. yhteys- ja katkaisutapahtumat) sekä yhteyksien ryhmittelyn.
SignalR voi hallita yhteyksiä automaattisesti. Ja voit lähettää lähetysviestejä kaikille yhdistetyille asiakkaille, aivan kuten chat-huoneessa. Tietenkin, massalähettämisen lisäksi voit lähettää viestejä myös tietyille asiakkaille. Yhteys asiakkaan ja palvelimen välillä on pysyvä, toisin kuin perinteinen HTTP-protokolla, joka vaatii yhteyden uudelleen muodostamista jokaista viestintää varten.
SignalR tukee "server push" -ominaisuutta, jossa palvelinkoodi voi kutsua asiakaskoodia selaimessa käyttämällä etäproseduurikutsuja (RPC) sen sijaan, että kyse olisi tällä hetkellä verkossa yleisesti käytetyistä pyynnöistä – vastaavasta käsittelymallista.
SignalR-sovelluksia voidaan laajentaa tuhansille asiakkaille Service Busin, SQL SERVERin tai Redisin avulla.
SignalR on avoimen lähdekoodin ja siihen pääsee käsiksi GitHubin kautta.
2. SignalR ja WebSocket
ignalR käyttää WebSocket-siirtomenetelmää – aina kun mahdollista. Ja vaihtaa automaattisesti vanhaan siirtomenetelmään (esim. HTTP-pitkä yhteys). Voit toki kirjoittaa sovelluksesi suoraan WebSocketsilla, mutta SignalR:n käyttö tarkoittaa, että sinulla on enemmän lisätoimintoja ilman, että sinun tarvitsee keksiä pyörää uudelleen. Tärkeintä on, että voit keskittyä liiketoiminnan toteutukseen ajattelematta yhteensopivan koodin luomista erikseen vanhalle asiakkaalle. SignalR mahdollistaa myös huolen välttämisen WebSocket-päivityksistä, sillä SignalR:ää päivitetään jatkossakin tukemaan taustalla olevien siirtomenetelmien muuttamista, jotta sovellusten eri WebSocket-versioiden käyttöliittymä olisi johdonmukainen.
Tietenkin voit luoda ratkaisun, joka käyttää vain WebSocket-siirtoa, ja SignalR tarjoaa kaikki ominaisuudet, joita saatat tarvita oman koodin kirjoittamiseen, kuten palaamisen muihin siirtomenetelmiin ja sovelluksen muokkaamisen uudempiin WebSocket-toteutuksiin.
3. Kuljetus ja paluu
SignalR on abstraktio siirtoteknologiasta, jota tarvitaan reaaliaikaisten toimintojen toteuttamiseen asiakkaiden ja palvelimien välillä. SignalR aloittaa yhteyden HTTP:llä ja tarkistaa, onko WebSocket käytettävissä – jos varma, päivitä WebSocketin yhteyteen. WebSocket on ihanteellisin siirtotapa SignalR:lle, koska se käyttää palvelinmuistia tehokkaimmin, tarjoaa alhaisimman viiveen ja kattavat taustatoiminnot (kuten täysdupleksiviestintä asiakkaan ja palvelimen välillä), mutta sillä on myös tiukimmat vaatimukset: palvelimen on käytettävä Windows Server 2012- tai Windows 8 -käyttöjärjestelmää samanaikaisesti. .NET frameworkin versio 4.5 ja uudemmat. Jos näitä vaatimuksia ei täytetä, SignalR yrittää käyttää vaihtoehtoista siirtotapaa yhdistämiseen.
4. HTML5-toimitus
Käytetty siirtotapa riippuu siitä, tukeeko asiakasselain HTML5:ttä, muuten käytetään vanhaa siirtomenetelmää.
WebSocket (jos sekä palvelin että selain tukevat WebSocketia). WebSocket on ainoa tapa luoda aito ja kestävä kaksisuuntainen yhteys sekä asiakas- että palvelinpuolelle. Tietenkin WebSocketilla on myös tiukimmat vaatimukset: sitä tuetaan vain uusimmissa IE-, Chrome- ja FF-versioissa, ja se on toteutettu vain osittain muissa selaimissa, kuten Operassa ja Safarissa.
Palvelin lähettää tapahtumia, joita kutsutaan myös nimellä EventSource (jos selain tukee palvelinlähetyksiä, käytännössä kaikki selaimet paitsi IE tukevat tätä ominaisuutta).
5. Komeetan siirto
Seuraavat siirtotyypit perustuvat Comet-verkkosovellusmalliin, jossa selain tai asiakas ylläpitää pitkää HTTP-yhteyspyyntöä, ja palvelin voi lähettää datan asiakkaalle ilman suoraa pyyntöä asiakkaalta.
Forever Frame (vain IE) Forever Frame luo piilotetun IFramen, joka lähettää palvelimelle pyynnön, jota ei saada valmiiksi. Palvelin lähettää jatkuvasti skriptejä asiakkaalle, ja asiakas suorittaa ne välittömästi, eli palvelimelta asiakkaalle on yksisuuntainen reaaliaikainen yhteys. Asiakas-palvelin-yhteys käyttää eri yhteyttä kuin kyseinen yhteys. Esimerkiksi tavallinen HTML-pyyntö luo uuden yhteyden jokaiselle lähetetylle datalle.
Ajaxin pitkä kysely ei luo pysyvää yhteyttä, vaan kyselyt tekevät jatkuvasti pyyntöjä palvelimelle. Odota, että palvelin vastaa, sulje yhteys jokaisella yhteydellä, ja tee sitten heti uusi pyyntö. Tämä aiheuttaa tietysti viivettä, kun yhteys nollataan ja yhdistetään uudelleen.
Lisätietoja eri konfiguraatioiden tukemista kuljetusmenetelmistä löytyy kohdasta Tuetut alustat. (IE vaatii 8 tai enemmän, muut selaimet ovat nykyinen versio -1)
Siirtomenetelmän valintaprosessi
Seuraava lista näyttää, miten SignalR päättää, mitä tyyppiä käytetään lähetykseen.
IE8 ja aiemmat käyttävät pitkää kyselyä.
Jos JSONP on konfiguroitu (eli jsonp-parametri on tosi yhdistettäessä), käytä pitkää kyselyä.
Jos käytät verkkotunnusten välistä yhteyttä (eli SignalR-päätepiste ja sivu eivät ole samassa domainissa), käytä WebSocketsia, jos seuraavat ehdot täyttyvät:
Asiakasohjelma tukee Cross-Domain Resource Sharing (CORS) -toimintoa, katso CORS lisätietoja varten
Asiakasohjelma tukee WebSocketia
Palvelin tukee WebSocketia
Jos jokin yllä mainituista ehdoista ei täytty, käytetään pitkää kyselyä. Lisätietoja verkkotunnusten välisistä yhteyksistä löytyy kohdasta Kuinka määrittää verkkotunnusten väliset yhteydet.
Jos et konfiguroi JSONP:n käyttöä eikä yhteys ole monitoimialueinen, käytä WebSocketia, tietenkin, kunhan sekä asiakas että palvelin tukevat WebSocketia.
Jos asiakas tai palvelin ei tue WebSocketeja, käytä palvelinta tapahtumien lähettämiseen.
Jos palvelin lähettää tapahtuman, joka ei ole käytettävissä, käytä Forever Framea.
Jos Forever Frame ei ole käytettävissä, käytä pitkää kyselyä.
Monitorin siirto
Voit nähdä, mitä siirtotapaa sovelluksesi käyttää ottamalla Hub-lokitukset käyttöön ja selaimesi konsolissa.
Lokituksen mahdollistamiseksi lisää seuraava komento asiakassovellukseen:
nnection.hub.logging = totta;
6. Tarkastus ja kuljetus:
Voit nähdä, mitä siirtotapaa sovelluksesi käyttää ottamalla Hub-lokitukset käyttöön ja selaimesi konsolissa. Lokituksen mahdollistamiseksi lisää seuraava komento asiakassovellukseen:
nnection.hub.logging = totta;
$.connection.hub.logging = totta;
IE:ssä paina F12 avataksesi kehittäjätyökalut ja klikkaa Console-välilehteä.
Chromessa paina Ctrl+Shift+J avataksesi konsolin
Seuraamalla kirjautumista konsolissa näet SignalR:n käyttämän lähetysmenetelmän.
7. Nimetty laivaliikenne:
Siirtotavan neuvottelu vaatii tietyn ajan ja palvelimen/asiakkaan resurssit. Jos asiakasympäristö on tiedossa, siirtotapa voidaan määrittää yhteyden aloittamisen yhteydessä suorituskyvyn parantamiseksi. Seuraava koodi osoittaa Ajaxin pitkän kyselyn käytön suoraan yhteyden alkaessa, jos asiakas tunnetaan tukevan jotain muuta protokollaa:
connection.start({ kuljetus: 'longPolling' });
Jos haluat, että asiakas neuvottelee kuljetuksesta tietyssä järjestyksessä, voit määrittää, missä järjestyksessä neuvottelu yritetään tehdä. Alla oleva koodi näyttää, miten kokeilla ensin WebSocketsia ja käyttää pitkää kyselyä heti epäonnistumisen jälkeen.
connection.start({ siirto: ['webSockets','longPolling'] });
Käyttäjän määrittelemät merkkijonovakiot määritellään seuraavasti:
webSockets
forverFrame
serverSentEvents
longPolling
8. Yhteydet ja keskukset SignalR API sisältää kaksi asiakas-palvelin-viestintämallia: pysyvät yhteydet ja hubit.
Yhteys on yksinkertainen päätepiste yksittäisen, ryhmitellyn tai lähetetyn viestin lähettämiseen. PersistentConnection API (joka esitetään .NET-koodissa PersistentConnection-luokkana) antaa kehittäjille suoran pääsyn SignalR:n taustalla olevaan viestintäprotokollaan. Kehittäjät, jotka ovat käyttäneet yhteyspohjaisia rajapintoja kuten WCF, tuntevat yhteysviestintämallin paremmin.
Hubit ovat API-pohjaisia, mutta korkeamman tason viestintäputkia, joiden avulla asiakkaat ja palvelimet voivat kutsua metodeja suoraan toisilleen. SignalR hoitaa erinomaista työtä konerajat ylittävässä aikataulutuksessa, mahdollistaen asiakkaiden helposti kutsua metodeja palvelimella ikään kuin ne kutsuisivat paikallisia metodeja, ja päinvastoin. Kehittäjät, jotka ovat käyttäneet etäpuhelupohjaisia AIP:itä, kuten .Net Remotingia, tuntevat hub-mallin paremmin. Hubin avulla voit myös välittää vahvasti tyypitetyt parametrit metodeille ja sitoa ne malliin.
Arkkitehtuurikaavio: Alla oleva kaavio näyttää keskittimen, jatkuvan yhteyden ja kuljetukseen käytetyn teknologian välisen suhteen.
9. Miten keskus toimii:
Kun palvelinkoodi kutsuu asiakasta, palvelin lähettää paketin, joka sisältää kutsuvan metodin ja parametrit (kun objektia käytetään metodiparametrina, se sarjoitetaan JSON-muodossa lähetettäväksi). Asiakas tarkistaa vastaanotetun metodin nimen ja suorittaa vastaavuushaun asiakkaan määrittelemässä metodissa, ja jos vastaavuus onnistuu, metodi suoritetaan ja deserialisoitu objekti toimii metodiparametrina.
Voit käyttää työkaluja kuten Fiddler metodikutsun suorituksen seuraamiseen. Seuraava kuva esittää menetelmän, joka on tallennettu Fiddlerin lokeista ja lähetetään SignalR-palvelimelta verkkoselaimen asiakkaalle. Hubista käynnistetty metodi on nimeltään MoveShapeHub, ja metodi nimeltä updateShape.
Tässä esimerkissä hubin nimi tunnistetaan parametrilla "H", metodin nimi parametrilla "M" ja metodille lähetetty parametriobjekti tunnistetaan parametrilla "A". Viestin tuottanut sovellus toteutettiin korkeataajuisessa reaaliaikaisessa viestinnän tutoriaalissa.
Valitse viestintämalli:
Useimmat sovellukset käyttävät hubin API:a, jota voidaan käyttää seuraavissa tilanteissa:
Sinun täytyy määritellä, missä muodossa viesti lähetetään.
Kehittäjät suosivat viestintä- ja aikataulutusmallia etäpuhelumallin sijaan
Viestimallia käytetään nykyisissä sovelluksissa ja sen on tarkoitus siirtää SignalR:ään.
|
Julkaistu 5.7.2017 10.21.40
|
|
|
|
Vuokraisäntä