1. Co je SignalR:
ASP.NET SignalR je knihovna tříd poskytovaná vývojáři pro zjednodušení procesu přidávání živého webového obsahu do aplikací. Funkčnost webu v reálném čase znamená, že serverový kód může aktivně posílat obsah klientům kdykoli, místo aby server čekal na požadavek od klienta (než vrátí obsah).
Všechny "živé" typy webových funkcí lze přidat do ASP.NET aplikace pomocí SignalR. Nejčastěji používaným příkladem jsou chatovací místnosti, ale můžeme udělat mnohem víc. Zvažte následující situace: uživatelé musí neustále obnovovat webovou stránku, aby viděli nejnovější data; Nebo načíst (a zobrazit) nová data na stránce implementací dlouhého pollingu, pak můžete zvážit použití SignalR. Například: dashboardy a monitorovací aplikace; Spolupracující aplikace (např. více lidí upravujících dokumenty současně); Aktualizace pracovního pokroku a prezentační formuláře v reálném čase atd.
SignalR je také vhodný pro novější typy webových aplikací, které vyžadují časté aktualizace ze serveru, například pro hraní her v reálném čase. Tady je dobrý příklad: ShoorR.
SignalR poskytuje jednoduché API, které uživatelům umožňuje vytvářet vzdálené volání procedur server-klient (RPC), ke kterým lze snadno přistupovat ze strany serveru. Síťový kód. SignalR také zahrnuje spojení (např. události připojení a odpojení) a seskupování spojení.
SignalR dokáže automaticky spravovat spojení. A umožňuje vám posílat vysílací zprávy všem propojeným klientům, stejně jako chatovací místnost. Samozřejmě, kromě hromadného odesílání můžete také posílat zprávy konkrétním klientům. Spojení mezi klientem a serverem je trvalé, na rozdíl od tradičního HTTP protokolu, který vyžaduje obnovení spojení pro každou komunikaci.
SignalR podporuje funkci "server push", kdy serverový kód může volat klientský kód v prohlížeči pomocí vzdálených volání procedur (RPC) místo požadavků, které jsou běžně používané na webu – tedy odpovídající model zpracování.
Aplikace SignalR lze rozšířit na tisíce klientů pomocí Service Bus, SQL SERVER nebo Redis.
SignalR je open-source a lze k němu přistupovat přes GitHub.
2. SignalR a WebSocket
ignalR používá metodu WebSocket – pokud je to možné. A automaticky přepínají na starý způsob přenosu (např. HTTP dlouhé připojení). Aplikaci můžete samozřejmě napsat přímo pomocí WebSockets, ale použití SignalR znamená, že budete mít více funkcí navíc, aniž byste museli vynalézat kolo znovu. Nejdůležitější je, že se můžete soustředit na obchodní implementaci, aniž byste museli přemýšlet o vytváření kompatibilního kódu zvlášť pro starého klienta. SignalR vám také umožňuje vyhnout se obavám z aktualizací WebSocketu, protože SignalR bude nadále aktualizován, aby podporoval měnící se základní transportní metody a poskytoval konzistentní přístupové rozhraní pro aplikace napříč různými verzemi WebSockets.
Samozřejmě můžete vytvořit řešení, které používá pouze WebSocket transport, a SignalR poskytuje všechny funkce, které můžete potřebovat k napsání vlastního kódu, například návrat k jiným transportním metodám a úprava aplikace pro novější WebSocket implementace.
3. Doprava a návrat
SignalR je abstrakcí transportní technologie potřebné k implementaci funkcí v reálném čase mezi klienty a servery. SignalR nejprve spustí spojení pomocí HTTP a zkontroluje, zda je WebSocket dostupný – pokud ano, aktualizujte připojení WebSocketu. WebSocket je nejideálnější způsob přenosu pro SignalR, protože nejefektivněji využívá paměť serveru, má nejnižší latenci a komplexní základní funkce (například plno-duplexní komunikaci mezi klientem a serverem), ale zároveň splňuje nejpřísnější požadavky: server musí používat operační systém Windows Server 2012 nebo Windows 8 a současně. .NET framework verze 4.5 a vyšší. Pokud tyto požadavky nejsou splněny, SignalR se pokusí použít alternativní způsob přenosu k připojení.
4. HTML5 distribuce
Použitá metoda přenosu závisí na tom, zda klientský prohlížeč podporuje HTML5, jinak bude použit starý způsob přenosu.
WebSocket (pokud WebSocket podporují jak server, tak prohlížeč). WebSocket je jediný způsob, jak navázat skutečné a trvalé obousměrné spojení jak na straně klienta, tak serveru. Samozřejmě, WebSocket má také nejpřísnější požadavky: je podporován pouze v nejnovějších verzích IE, Chrome a FF a je jen částečně implementován v jiných prohlížečích, jako jsou Opera a Safari.
Server odesílá události, známé také jako EventSource (pokud prohlížeč podporuje odesílání událostí na server, v podstatě všechny prohlížeče kromě IE tuto funkci podporují).
5. Přenos na kometu
Následující typy transportu jsou založeny na modelu webové aplikace Comet, kde prohlížeč nebo klient udržuje dlouhý HTTP požadavek na připojení a server může klientovi posílat data bez explicitního požadavku od klienta.
Forever Frame (pouze IE) Forever Frame vytvoří skrytý IFrame, který odešle serveru požadavek, který nebude dokončen. Server pak nepřetržitě posílá skripty klientovi a klient je okamžitě vykonává, tj. jednosměrné reálné připojení ze serveru ke klientovi. Klient-server spojení používá jiné spojení než toto připojení. Například standardní HTML požadavek vytvoří nové spojení pro každé odeslané data.
Dlouhé dotazování v Ajaxu nevytváří trvalé spojení, ale spíše dotazuje neustálým posíláním požadavků na server. Počkejte na odpověď serveru a u každého připojení ukončete a pak ihned pošlete nový požadavek. Samozřejmě to způsobí určité zpoždění při resetování a opětovném připojení spojení.
Informace o transportních metodách podporovaných různými konfiguracemi naleznete v sekci Podporované platformy. (IE vyžaduje 8 nebo více, jiné prohlížeče jsou aktuální verze -1)
Proces výběru metody přenosu
Následující seznam ukazuje, jak SignalR rozhoduje, který typ použije pro přenos.
IE8 a starší používejte dlouhé pollingy.
Pokud je JSONP nakonfigurován (tj. parametr jsonp je při připojení nastaven na true), použijte dlouhé polling.
Pokud používáte cross-domain připojení (tj. koncový bod SignalR a stránka nejsou ve stejné doméně), použijte WebSockets, pokud jsou splněny následující podmínky:
Klient podporuje sdílení zdrojů napříč doménami (CORS), podrobnosti viz CORS na
Klient podporuje WebSocket
Server podporuje WebSocket
Pokud není splněna některá z výše uvedených podmínek, použije se dlouhý průzkum. Pro více informací o mezidoménových spojeních viz Jak navázat mezidoménová spojení.
Pokud nenastavíte používání JSONP a připojení není cross-domain, použijte samozřejmě WebSocket, pokud WebSocket podporují jak klient, tak server.
Pokud klient nebo server WebSockets nepodporuje, použijte server k odesílání událostí.
Pokud server odešle událost není dostupná, použijte Forever Frame.
Pokud Forever Frame není dostupný, použijte dlouhé ankety.
Monitorování přenosu
Způsob transportu vaší aplikace můžete vidět zapnutím Hub logování a v konzoli prohlížeče.
Pro povolení logování přidejte do klientské aplikace následující příkaz:
nnection.hub.logging = pravda;
6. Inspekce a přeprava:
Způsob transportu vaší aplikace můžete vidět zapnutím Hub logování a v konzoli prohlížeče. Pro povolení logování přidejte do klientské aplikace následující příkaz:
nnection.hub.logging = pravda;
$.connection.hub.logging = pravda;
V IE stiskněte F12 pro otevření vývojářských nástrojů a klikněte na záložku Konzole.
V Chromu stiskněte Ctrl+Shift+J pro otevření konzole
Při sledování logování v konzoli můžete vidět způsob přenosu, který SignalR používá.
7. Určená přeprava:
Vyjednávání způsobu přenosu vyžaduje určitý čas a zdroje serveru/klienta. Pokud je klientské prostředí známo, lze při zahájení připojení určit transportní metodu pro zlepšení výkonu. Následující kód demonstruje použití dlouhého dotazování Ajaxu přímo při zahájení spojení, pokud je známo, že klient podporuje jiný protokol:
connection.start({ transport: 'longPolling' });
Pokud chcete, aby klient vyjednával přepravu v určitém pořadí, můžete určit pořadí, ve kterém se pokus o vyjednávání uskutečňuje. Níže uvedený kód ukazuje, jak nejprve vyzkoušet WebSockets a po selhání použít dlouhé dotazování.
connection.start({ transport: ['webSockets','longPolling'] });
Řetězcové konstanty, které uživatel zadává, jsou definovány následovně:
webSockets
forverFrame
serverSentEvents
longPolling
8. Připojení a huby API SignalR zahrnuje dva modely komunikace klient-server: trvalá připojení a huby.
Spojení představuje jednoduchý koncový bod pro odeslání jediné, skupinové nebo broadcastované zprávy. API PersistentConnection (reprezentované třídou PersistentConnection v .NET kódu) dává vývojářům přímý přístup k základnímu komunikačnímu protokolu SignalR. Vývojáři, kteří používali API založená na spojení, jako je WCF, budou lépe obeznámeni s modelem komunikace spojení.
Huby jsou API založené, ale vyšší úrovně komunikační pipeline, které umožňují klientům a serverům volat metody přímo mezi sebou. SignalR skvěle zvládá plánování mezi stroji, umožňuje klientům snadno volat metody na serveru, jako by volali lokální metody, a naopak. Vývojáři, kteří používali AIP založené na vzdálených hovorech, jako je .Net Remoting, budou s modelem hubu více obeznámeni. Pomocí hubu můžete také předávat silně typované parametry metodám a navázat je na model.
Schéma architektury: Níže uvedený diagram ukazuje vztah mezi centrem, kontinuálním spojením a technologií používanou pro dopravu.
9. Jak hub funguje:
Když serverový kód volá klienta, server odešle klientovi paket obsahující volající metodu a parametry (když je objekt použit jako parametr metody, bude serializován jako JSON pro odeslání). Klient poté zkontroluje přijaté jméno metody a provede vyhledávání shody v klientem definované metodě, a pokud je shoda úspěšná, metoda se vykoná a deserializovaný objekt se použije jako parametr metody.
Můžete použít nástroje jako Fiddler ke sledování provádění volání metody. Následující obrázek ukazuje metodu zachycenou z logů Fiddleru, která má být odeslána ze serveru SignalR do klienta webového prohlížeče. Metoda iniciovaná z hubu se nazývá MoveShapeHub a metoda se jmenuje updateShape.
V tomto příkladu je název uzlu identifikován s parametrem "H", název metody s parametrem "M" a objekt parametru zaslaný metodě je identifikován s parametrem "A". Aplikace, která zprávu generovala, byla implementována v tutoriálu komunikace s vysokou frekvencí v reálném čase.
Vyberte si model komunikace:
Většina aplikací používá API hubu, které lze využít v následujících situacích:
Musíte specifikovat formát, ve kterém je zpráva odeslána.
Vývojáři dávají přednost modelu zasílání zpráv a plánování před modelem vzdálených hovorů
Model zasílání zpráv se používá v existujících aplikacích a plánuje se jeho portování na SignalR.
|
Zveřejněno 05.07.2017 10:21:40
|
|
|
|
Pronajímatel