1. Kas ir SignalR:
ASP.NET SignalR ir nodarbību bibliotēka, kas tiek nodrošināta, lai vienkāršotu izstrādes izstrādātāju tiešraides tīmekļa satura pievienošanas procesu lietojumprogrammām. Reāllaika tīmekļa funkcionalitāte attiecas uz servera koda atļauju jebkurā laikā aktīvi virzīt saturu klientiem, nevis serverim gaidīt klienta pieprasījumu (pirms satura atgriešanas).
Visu "dzīvo" tīmekļa funkcionalitāti var pievienot jūsu ASP.NET lietojumprogrammai, izmantojot SignalR. Visbiežāk izmantotais piemērs ir tērzēšanas istabas, bet mēs varam darīt daudz vairāk. Apsveriet šādas situācijas: lietotājiem ir pastāvīgi jāatsvaidzina tīmekļa lapa, lai redzētu jaunākos datus; Vai arī izgūstiet (un parādiet) jaunus datus lapā, ieviešot garu aptauju, tad varat apsvērt iespēju izmantot SignalR, lai to izdarītu. Piemēram: informācijas paneļi un uzraudzības lietojumprogrammas; Sadarbības lietojumprogrammas (piemēram, vairāki cilvēki vienlaicīgi rediģē dokumentus); Darba progresa atjauninājumi un reāllaika prezentācijas veidlapas utt.
SignalR ir piemērots arī jaunākiem tīmekļa lietojumprogrammu veidiem, kuriem nepieciešami augstas frekvences atjauninājumi no servera, piemēram, reāllaika spēlēm. Šeit ir labs piemērs: ShoorR.
SignalR nodrošina vienkāršu API, lai lietotāji varētu izveidot servera-klienta attālo procedūru izsaukumus (RPC), kuriem var viegli piekļūt no servera puses. Neto kods. SignalR ietver arī savienojumus (piemēram, savienojuma un atvienošanas notikumus) un savienojumu grupēšanu.
SignalR var automātiski pārvaldīt savienojumus. Un ļauj nosūtīt apraides ziņojumus visiem savienotajiem klientiem, gluži kā tērzētavā. Protams, papildus masveida nosūtīšanai varat arī nosūtīt ziņojumus konkrētiem klientiem. Savienojums starp klientu un serveri ir pastāvīgs, atšķirībā no tradicionālā HTTP protokola, kas prasa atjaunot savienojumu katrai saziņai.
SignalR atbalsta "servera push" funkciju, kur servera kods var izsaukt klienta kodu pārlūkprogrammā, izmantojot attālās procedūras zvanus (RPC), nevis pieprasījumus, kas pašlaik parasti tiek izmantoti tīmeklī - atbilstošo apstrādes modeli.
SignalR lietojumprogrammas var paplašināt līdz tūkstošiem klientu, izmantojot Service Bus, SQL SERVER vai Redis.
SignalR ir atvērtā koda, un tam var piekļūt, izmantojot GitHub.
2. SignalR un WebSocket
ignalR izmanto WebSocket transportēšanas metodi - kur tas ir iespējams. Un automātiski pārslēdzieties uz veco transporta metodi (piemēram, HTTP garo savienojumu). Jūs noteikti varat rakstīt savu lietojumprogrammu tieši ar WebSockets, bet SignalR izmantošana nozīmē, ka jums būs vairāk papildu funkcionalitātes, neizgudrojot riteni no jauna. Vissvarīgākais ir tas, ka jūs varat koncentrēties uz biznesa īstenošanu, nedomājot par saderīga koda izveidi atsevišķi vecajam klientam. SignalR arī ļauj jums izvairīties no uztraukuma par WebSocket atjauninājumiem, jo SignalR turpinās tikt atjaunināts, lai atbalstītu mainīgās transportēšanas metodes, lai nodrošinātu konsekventu piekļuves interfeisu lietojumprogrammām dažādās WebSockets versijās.
Protams, jūs varat izveidot risinājumu, kas izmanto tikai WebSocket transportu, un SignalR nodrošina visas funkcijas, kas jums var būt nepieciešamas, lai rakstītu savu kodu, piemēram, atgriezties pie citām transporta metodēm un modificēt lietojumprogrammu jaunākām WebSocket implementācijām.
3. Transportēšana un atgriešana
SignalR ir transporta tehnoloģijas abstrakcija, kas nepieciešama, lai ieviestu reālā laika funkcijas starp klientiem un serveriem. SignalR vispirms sāk savienojumu ar HTTP un pārbauda, vai WebSocket ir pieejams - ja tas ir pārliecināts, jauniniet uz WebSocket savienojumu. WebSocket ir ideālākā SignalR pārraides metode, jo tā visefektīvāk izmanto servera atmiņu, tai ir viszemākais latentums un visaptverošas pamatfunkcijas (piemēram, pilna dupleksa komunikācija starp klientu un serveri), bet tai ir arī visstingrākās prasības: serverim jāizmanto Windows Server 2012 vai Windows 8 operētājsistēma un tajā pašā laikā. .NET framework versija 4.5 un jaunāka. Ja šīs prasības netiek izpildītas, SignalR mēģinās izmantot alternatīvu pārraides metodi, lai izveidotu savienojumu.
4. HTML5 piegāde
Izmantotā transportēšanas metode ir atkarīga no tā, vai klienta pārlūkprogramma atbalsta HTML5, pretējā gadījumā tiks izmantota vecā transportēšanas metode.
WebSocket (ja gan serveris, gan pārlūkprogramma atbalsta WebSocket). WebSocket ir vienīgais veids, kā izveidot patiesu un izturīgu divvirzienu savienojumu gan klienta, gan servera pusē. Protams, WebSocket ir arī visstingrākās prasības: tas tiek atbalstīts tikai jaunākajās IE, Chrome un FF versijās, un tas ir tikai daļēji ieviests citās pārlūkprogrammās, piemēram, Opera un Safari.
Serveris sūta notikumus, kas pazīstami arī kā EventSource (ja pārlūkprogramma atbalsta servera sūtīšanas notikumus, būtībā visas pārlūkprogrammas, izņemot IE, atbalsta šo funkciju).
5. Komētas transmisija
Tālāk norādītie transporta veidi ir balstīti uz Comet tīmekļa lietojumprogrammas modeli, kur pārlūkprogramma vai klients uzturēs ilgu HTTP savienojuma pieprasījumu, un serveris var nosūtīt datus klientam bez skaidra klienta pieprasījuma.
Forever Frame (tikai IE) Forever Frame izveidos slēptu IFrame, kas nosūtīs serverim pieprasījumu, kas netiks pabeigts. Pēc tam serveris nepārtraukti nosūta skriptus klientam, un klients tos nekavējoties izpilda, t.i., vienvirziena reāllaika savienojums no servera uz klientu. Klienta-servera savienojums izmanto citu savienojumu, nevis šo savienojumu. Piemēram, standarta HTML pieprasījums izveido jaunu savienojumu katram nosūtītajam datumam.
Ajax garā aptauja nerada pastāvīgu savienojumu, bet drīzāk aptaujas, pastāvīgi veicot pieprasījumus serverim. Pagaidiet, līdz serveris atbild un aizver šo savienojumu katrā savienojumā, un pēc tam nekavējoties veiciet jaunu pieprasījumu. Protams, tas radīs zināmu aizkavēšanos, kad savienojums tiek atiestatīts un atkārtoti savienots.
Informāciju par dažādu konfigurāciju atbalstītajām transportēšanas metodēm skatiet sadaļā Atbalstītās platformas. (IE prasa 8 vai augstāku, citas pārlūkprogrammas ir pašreizējā versija -1)
Pārsūtīšanas metodes izvēles process
Šajā sarakstā ir parādīts, kā SignalR izlemj, kuru veidu izmantot pārraidei.
IE8 un agrāk izmantojiet garu aptauju.
Ja JSONP ir konfigurēts (t.i., savienojuma laikā jsonp parametrs ir iestatīts uz true), izmantojiet garu aptauju.
Ja izmantojat starpdomēnu savienojumu (t.i., SignalR galapunkts un lapa neatrodas vienā domēnā), izmantojiet WebSockets, ja ir izpildīti šādi nosacījumi:
Klients atbalsta starpdomēnu resursu koplietošanu (Cross-Domain Resource Sharing — CORS), detalizētu informāciju skatiet sadaļā CORS
Klients atbalsta WebSocket
Serveris atbalsta WebSocket
Ja kāds no iepriekš minētajiem nosacījumiem nav izpildīts, tiek izmantota gara aptauja. Papildinformāciju par starpdomēnu savienojumiem skatiet sadaļā Kā izveidot starpdomēnu savienojumus.
Ja nekonfigurējat JSONP izmantošanu un savienojums nav starpdomēns, protams, izmantojiet WebSocket, ja gan klients, gan serveris atbalsta WebSocket.
Ja klients vai serveris neatbalsta WebSockets, izmantojiet serveri, lai sūtītu notikumus.
Ja serveris nosūta notikumu, kas nav pieejams, izmantojiet Forever Frame.
Ja Forever Frame nav pieejams, izmantojiet garu aptauju.
Pārraides uzraudzība
Varat redzēt, kādu transportēšanas metodi izmanto jūsu lietojumprogramma, iespējojot centrmezgla reģistrēšanu un pārlūkprogrammas konsolē.
Lai iespējotu reģistrēšanu, pievienojiet klienta lietojumprogrammai šādu komandu:
nnection.hub.logging = patiess;
6. Pārbaude un transportēšana:
Varat redzēt, kādu transportēšanas metodi izmanto jūsu lietojumprogramma, iespējojot centrmezgla reģistrēšanu un pārlūkprogrammas konsolē. Lai iespējotu reģistrēšanu, pievienojiet klienta lietojumprogrammai šādu komandu:
nnection.hub.logging = patiess;
$.connection.hub.logging = true;
IE nospiediet taustiņu F12, lai atvērtu izstrādātāja rīkus, un noklikšķiniet uz cilnes Konsole.
Pārlūkā Chrome nospiediet taustiņu kombināciju Ctrl+Shift+J, lai atvērtu konsoli
Novērojot reģistrēšanu konsolē, jūs varat redzēt pārraides metodi, ko izmanto SignalR.
7. Izraudzītā piegāde:
Pārraides metodes apspriešana prasa noteiktu laiku un servera/klienta resursus. Ja klienta vide ir zināma, tad transportēšanas metodi var norādīt, kad savienojums tiek uzsākts, lai uzlabotu veiktspēju. Šis kods parāda, ka Ajax garās aptaujas izmantošana tieši savienojuma uzsākšanas brīdī, ja ir zināms, ka klients atbalsta jebkuru citu protokolu:
connection.start({ transports: 'longPolling' });
Ja vēlaties, lai klients vienotos par transportu noteiktā secībā, varat norādīt secību, kādā tiek mēģinātas sarunas. Zemāk redzamais kods parāda, kā vispirms mēģināt izmantot WebSockets un izmantot garu aptauju uzreiz pēc neveiksmes.
connection.start({ transport: ['webSockets','longPolling'] });
Lietotāja norādītās virknes konstantes ir definētas šādi:
tīmekļa ligzdas
forverFrame
serverSentEvents
ilgstoša aptauja
8. Savienojumi un centrmezgli SignalR API ietver divus klienta-servera sakaru modeļus: pastāvīgos savienojumus un centrmezglus.
Savienojums ir vienkāršs galapunkts atsevišķa, grupēta vai apraides ziņojuma nosūtīšanai. PersistentConnection API (ko pārstāv PersistentConnection klase .NET kodā) nodrošina izstrādātājiem tiešu piekļuvi SignalR pamatā esošajam sakaru protokolam. Izstrādātāji, kuri ir izmantojuši savienojuma API, piemēram, WCF, būs labāk iepazinušies ar savienojuma sakaru modeli.
Centrmezgli ir uz API balstīti, bet augstāka līmeņa sakaru cauruļvadi, kas ļauj klientiem un serveriem izsaukt metodes tieši viens otram. SignalR veic brīnišķīgu darbu, apstrādājot vairāku mašīnu plānošanu, ļaujot klientiem viegli izsaukt metodes serverī tā, it kā viņi zvanītu vietējām metodēm, un otrādi. Izstrādātāji, kuri ir izmantojuši attālinātus zvanu AIP, piemēram, .Net Remoting, būs labāk iepazinušies ar centrmezgla modeli. Izmantojot centrmezglu, jūs varat arī nodot stipri ierakstītus parametrus metodēm un piesaistīt tos modelim.
Arhitektūras diagramma: zemāk redzamajā diagrammā parādīta saistība starp mezglu, nepārtrauktu savienojumu un transportam izmantoto pamattehnoloģiju.
9. Kā darbojas centrmezgls:
Kad servera kods izsauc klientu, serveris klientam nosūtīs paketi, kas satur izsaukšanas metodi un parametrus (ja objekts tiek izmantots kā metodes parametrs, tas tiks serializēts kā nosūtāmais JSON). Pēc tam klients pārbauda saņemto metodes nosaukumu un veic atbilstības uzmeklēšanu klienta definētajā metodē, un, ja atbilstība ir veiksmīga, metode tiek izpildīta un deserializētais objekts tiek izmantots kā metodes parametrs.
Varat izmantot tādus rīkus kā Fiddler, lai uzraudzītu metodes zvanu izpildi. Nākamajā attēlā redzama metode, kas iegūta no Fiddler žurnāliem, lai nosūtītu no SignalR servera uz tīmekļa pārlūkprogrammas klientu. Metodi, kas sākta no centrmezgla, sauc par MoveShapeHub, un metodi sauc par updateShape.
Šajā piemērā centrmezgla nosaukums tiek identificēts ar parametru "H", metodes nosaukums tiek identificēts ar parametru "M" un metodei nosūtītais parametra objekts tiek identificēts ar parametru "A". Lietojumprogramma, kas ģenerēja ziņojumu, tika ieviesta augstas frekvences reāllaika saziņas apmācībā.
Izvēlieties saziņas modeli:
Lielākā daļa lietojumprogrammu izmanto centrmezgla API, ko var izmantot šādās situācijās:
Jums jānorāda ziņojuma nosūtīšanas formāts.
Izstrādātāji dod priekšroku ziņojumapmaiņas un plānošanas modelim, nevis attālā zvana modelim
Ziņojumapmaiņas modelis tiek izmantots esošajās lietojumprogrammās, un to plānots pārnest uz SignalR.
|
Publicēts 05.07.2017 10:21:40
|
|
|
|
Saimnieks