1. Mi az a SignalR:
ASP.NET SignalR egy olyan osztálykönyvtár, amely a fejlesztők által elérhető élő webtartalom alkalmazásainak egyszerűsítésére szolgál. A valós idejű webfunkció azt jelenti, hogy a szerver kódja bármikor aktívan továbbíthatja a tartalmat az ügyfeleknek, ahelyett, hogy a szerver várna egy klienskérésre (mielőtt visszaküldené a tartalmat).
Minden "élő" webfunkció hozzáadható a ASP.NET alkalmazásodhoz a SignalR segítségével. A leggyakrabban használt példa a csevegőszobák, de ennél sokkal többet is tehetünk. Vegyük figyelembe a következő helyzeteket: a felhasználóknak folyamatosan frissíteniük kell az oldalt, hogy lássák a legfrissebb adatokat; Vagy hosszú felmérés alkalmazásával új adatokat kereshetsz (és megjelenítheted) az oldalon, majd fontolóra veheted a SignalR használatát. Például: irányítópultok és megfigyelő alkalmazások; Együttműködő alkalmazások (pl. több ember egyszerre szerkeszti a dokumentumokat); Munkafolyamat-frissítések és valós idejű prezentációs űrlapok stb.
A SignalR alkalmas újabb típusú webalkalmazásokhoz is, amelyek nagy frekvenciájú frissítéseket igényelnek a szervertől, például valós idejű játékhoz. Íme egy jó példa: ShoorR.
A SignalR egyszerű API-t biztosít a felhasználók számára, hogy szerver-kliens távoli eljáráshívásokat (RPC) hozzanak létre, amelyek könnyen elérhetők szerveroldalról. Net-kód. A SignalR tartalmaz kapcsolatokat (pl. csatlakozási és lekapcsolási eseményeket) és a kapcsolatcsoportosítást is.
A SignalR automatikusan képes kezelni a kapcsolatokat. És lehetővé teszi, hogy sugárzott üzeneteket küldj minden csatlakoztatott kliensnek, pont úgy, mint egy csevegőszobában. Természetesen a tömeges küldés mellett üzeneteket is küldhetsz konkrét kliensnek. A kliens és a szerver közötti kapcsolat tartós, ellentétben a hagyományos HTTP protokollral, amely minden kommunikációhoz a kapcsolat újraindítását igényli.
A SignalR támogatja a "szerver push" funkciót, ahol a szerver kódja a böngészőben távoli eljáráshívások (RPC) segítségével hívhatja a kliens kódot a jelenleg a weben gyakran használt kérések helyett – a megfelelő feldolgozási modellt.
A SignalR alkalmazások több ezer kliensre kiterjeszthetők Service Bus, SQL SERVER vagy Redis segítségével.
A SignalR nyílt forráskódú, és elérhető a GitHubon keresztül.
2. SignalR és WebSocket
az ignalR a WebSocket transzportációs módszert használja – ahol lehetséges. És automatikusan válthatsz a régi átviteli módszerre (pl. HTTP hosszú kapcsolat). Természetesen közvetlenül is megírhatod az alkalmazást WebSockets-szel, de a SignalR használatával több extra funkciód lesz anélkül, hogy újra kellene találnod a kereket. A legfontosabb, hogy az üzleti megvalósításra koncentrálhatsz anélkül, hogy külön összefüggő kódot kell létrehoznod a régi klienshez. A SignalR lehetővé teszi, hogy elkerüld a WebSocket frissítések miatti aggódást, mivel a SignalR továbbra is frissítve marad, hogy támogatja az alapvető szállítási módszerek megváltoztatását, hogy egységes hozzáférési felületet biztosítson a különböző WebSocket-verziók alkalmazásainak.
Természetesen létrehozhatsz olyan megoldást, amely csak WebSocket transzportot használ, és a SignalR minden szükséges funkciót biztosít a saját kód megírásához, például más átviteli módszerekhez való visszatérést és az alkalmazás módosítását újabb WebSocket megvalósításokhoz.
3. Szállítás és visszaküldés
A SignalR a transzfer technológia absztrakciója, amely valós idejű funkciók megvalósításához szükséges az ügyfelek és szerverek között. A SignalR először HTTP-vel indítja el a kapcsolatot, és ellenőrzi, hogy elérhető-e a WebSocket – ha biztos, frissítse a WebSocket csatlakozására. A WebSocket a legideálisabb átviteli módszer a SignalR számára, mert a szerver memóriáját a leghatékonyabban használja, a legalacsonyabb késleltetéssel és átfogó alapvető funkciókkal rendelkezik (például teljes duplex kommunikáció kliens és szerver között), ugyanakkor a legszigorúbb követelményeket is megköveteli: a szervernek Windows Server 2012 vagy Windows 8 operációs rendszert kell használnia, és egyidejűleg. .NET framework verzió 4.5 és annál magasabb. Ha ezek a követelmények nem teljesülnek, a SignalR alternatív átviteli módszert próbál alkalmazni a csatlakozásra.
4. HTML5 szállítás
A használt átviteli módszer attól függ, hogy a kliens böngésző támogatja-e a HTML5-et, különben a régi szállítási módszert fogják használni.
WebSocket (ha mind a szerver, mind a böngésző támogatja a WebSocketet). A WebSocket az egyetlen módja annak, hogy valódi és tartós kétirányú kapcsolatot alakítsunk ki mind kliens, mind szerver oldalon. Természetesen a WebSocket a legszigorúbb követelményeket is megmutatja: csak az IE, Chrome és FF legújabb verzióiban támogatják, és más böngészőkben, például az Operában és a Safariban csak részben van megvalósítva.
A szerver eseményeket küld, más néven EventSource (ha a böngésző támogatja szerverküldő eseményeket, akkor gyakorlatilag minden böngésző, kivéve IE-t, támogatja ezt a funkciót).
5. Üstökös átvitel
A következő transzfertípusok a Comet webalkalmazás-modellen alapulnak, ahol a böngésző vagy kliens hosszú HTTP kapcsolati kérést tart fenn, és a szerver explicit kérés nélkül továbbíthatja az adatokat az ügyfélnek.
Forever Frame (csak az Forever Frame) Forever Frame egy rejtett IFrame-ot hoz létre, amely egy kérést küld a szervernek, ami nem lesz teljes. A szerver ezután folyamatosan küld szkripteket az ügyfélnek, amelyeket azonnal végrehajt, azaz egyirányú valós idejű kapcsolatot teremt a szerver és az ügyfél között. Az ügyfél-szerver kapcsolat más kapcsolatot használ, mint az adott kapcsolat. Például egy szabványos HTML kérés új kapcsolatot hoz létre minden küldött adathoz.
Az Ajax hosszú lekérdezése nem teremt tartós kapcsolatot, hanem folyamatosan kér a szervert. Várd meg, amíg a szerver válaszol, és minden kapcsolatnál lezárod ezt a kapcsolatot, majd azonnal tegyél új kérést. Természetesen ez némi késleltetést okoz, amikor a kapcsolatot újraindítják és újracsatlakoztatják.
A különböző konfigurációk által támogatott szállítási módszerekről információért lásd: Támogatott platformok. (IE esetén 8 vagy annál magasabb verzió szükséges, más böngészők a jelenlegi verzió -1)
Átviteli módszer kiválasztása folyamata
Az alábbi lista bemutatja, hogyan dönti el a SignalR, melyik típust használja az adáshoz.
IE8 és korábbi verziókban használj hosszú szavazást.
Ha a JSONP be van állítva (azaz a jsonp paraméter igazra van állítva a csatlakozáskor), használj hosszú lekérdezést.
Ha több tartományos kapcsolatot használsz (azaz a SignalR végpont és az oldal nem ugyanabban a tartományban van), akkor használd WebSockets-t, ha az alábbi feltételek teljesülnek:
Az ügyfél támogatja a Cross-Domain Resource Sharing (CORS) rendszert, részletekért lásd a CORS oldalt
A kliens támogatja a WebSocketet
A szerver támogatja a WebSocketet
Ha a fenti feltételek egyike nem teljesül, hosszú szavazást alkalmaznak. További információért a doménmentes kapcsolatokról lásd: Hogyan lehet cross-domain kapcsolatokat létrehozni.
Ha nem konfigurálod a JSONP használatát, és a kapcsolat nem cross-domain, akkor természetesen használd a WebSocketet, feltéve, hogy mind a kliens, mind a szerver támogatja a WebSocketet.
Ha a kliens vagy szerver nem támogatja a WebSocketeket, használd a szervert események küldésére.
Ha a szerver eseményt küld, ami nem elérhető, használj Forever Frame-et.
Ha a Forever Frame nem elérhető, használj hosszú szavazást.
Monitor átvitel
A Hub naplózás engedélyezésével és a böngésző konzolján keresztül láthatod, milyen átviteli módszert használ az alkalmazásod.
A naplózás engedélyezéséhez a következő parancsot adjuk hozzá az ügyfélalkalmazásba:
nnection.hub.logging = true;
6. Ellenőrzés és szállítás:
A Hub naplózás engedélyezésével és a böngésző konzolján keresztül láthatod, milyen átviteli módszert használ az alkalmazásod. A naplózás engedélyezéséhez a következő parancsot adjuk hozzá az ügyfélalkalmazásba:
nnection.hub.logging = true;
$.connection.hub.logging = true;
IE-ben nyomd meg az F12 gombot, hogy megnyisd a fejlesztői eszközöket, és kattints a Konzol fülre.
A Chrome-ban nyomja meg a Ctrl+Shift+J gombot, hogy megnyissa a konzolt
A konzolban történő bejelentkezés megfigyelésével láthatod, milyen átviteli módszert használ a SignalR.
7. Kijelölt szállítás:
Az átviteli módszer tárgyalása bizonyos időt és a szerver/kliens erőforrásait igényel. Ha a kliens környezet ismert, akkor a szállítási módszer megadható a kapcsolat indításakor a teljesítmény javítása érdekében. Az alábbi kód bemutatja, hogyan használja az Ajax hosszú lekérdezését közvetlenül a kapcsolat indításakor, ha az ügyfél ismert, hogy támogatja bármely más protokollt:
connection.start({ transzport: 'longPolling' });
Ha azt szeretnéd, hogy egy ügyfél egy adott sorrendben tárgyaljon a szállításról, megadhatod, hogy milyen sorrendben próbálják meg a tárgyalást. Az alábbi kód bemutatja, hogyan próbáld ki először a WebSockets-et, és hogyan lehet közvetlenül a sikertelenség után hosszú lekérdezést alkalmazni.
connection.start({ transzport: ['webSockets','longPolling'] });
A felhasználó által meghatározott string állandók a következőképpen definiálódnak:
webSockets
forverFrame
serverSentEvents
longPolling
8. Kapcsolatok és hubok A SignalR API két kliens-szerver kommunikációs modellt tartalmaz: állandó kapcsolatokat és hubokat.
A kapcsolat egy egyszerű végpontot jelent egyetlen, csoportosított vagy sugárzott üzenet küldéséhez. A PersistentConnection API (amelyet a .NET kódban PersistentConnection osztály képvisel) közvetlen hozzáférést biztosít a fejlesztőknek a SignalR alapvető kommunikációs protokolljához. Azok a fejlesztők, akik már használtak kapcsolatalapú API-kat, például a WCF-et, jobban ismerik a kapcsolatkommunikációs modellt.
A hubok API-alapú, de magasabb szintű kommunikációs vezetékek, amelyek lehetővé teszik az ügyfelek és szerverek számára, hogy közvetlenül egymáshoz hívják a metódusokat. A SignalR remekül kezeli a gépeken átívelt ütemezést, lehetővé téve, hogy az ügyfelek könnyen meghívják a szerveren lévő metódusokat, mintha helyi metódusokat hívnának, és fordítva. Azok a fejlesztők, akik távoli hívásalapú AIP-ket, például a .Net Remotingot használtak, jobban ismerik a hub modellt. A hub segítségével erősen gépelt paramétereket is átadhatsz a metódusoknak, és kötheted őket a modellhez.
Architektúra diagram: Az alábbi ábra bemutatja a hub, a folyamatos kapcsolat és a szállításhoz használt technológia közötti kapcsolatot.
9. Hogyan működik a hub:
Amikor a szerver kódja hívja az klienst, a szerver egy csomagot küld a hívó metódust és paramétereket (amikor az objektumot metódusparaméterként használják, JSON-ként szeriázzák elküldésre) az ügyfélnek. A kliens ezután ellenőrzi a kapott metódusnevet, és egyeztetés keresést végez a kliens által definiált metódusban, és ha az egyezés sikeres, a metódus végrehajtódik, és a deserializált objektumot használják a metódusparaméterként.
Használhatsz olyan eszközöket, mint a Fiddler, hogy nyomon követd a metódushívás végrehajtását. Az alábbi kép egy Fiddler naplóiból rögzített módszert mutat, amelyet a SignalR szerverről a böngésző klienshez küldenek. A hubból indított módszert MoveShapeHub-nak hívják, a metódus pedig updateShape-nek.
Ebben a példában a hub nevét az "H" paraméterrel azonosítják, a metódus nevét az "M" paraméterrel, és a metódusnak küldött paraméterobjektumot az "A" paraméterrel. Az üzenetet generáló alkalmazást a nagyfrekvenciás valós idejű kommunikációs oktatóanyagban valósították meg.
Válassz kommunikációs modellt:
A legtöbb alkalmazás használja a hub API-ját, amely a következő helyzetekben használható:
Meg kell határoznod, hogy milyen formátumban küldik az üzenetet.
A fejlesztők inkább üzenetküldési és ütemezési modellt használnak a távoli hívás modell helyett
Az üzenetküldő modellt meglévő alkalmazásokban használják, és tervezik, hogy portolják SignalR-re.
|
Közzétéve 2017. 07. 05. 10:21:40
|
|
|
|
Háziúr