1. Ce este SignalR:
ASP.NET SignalR este o bibliotecă de clase oferite pentru a simplifica procesul de adăugare a conținutului web live în aplicații de către dezvoltatorii de dezvoltare. Funcționalitatea web în timp real se referă la permiterea codului serverului să trimită activ conținut către clienți în orice moment, în loc ca serverul să aștepte o cerere de la client (înainte de a returna conținutul).
Toate tipurile de funcționalități web "live" pot fi adăugate aplicației tale ASP.NET folosind SignalR. Cel mai des folosit exemplu sunt camerele de chat, dar putem face mult mai mult de atât. Luați în considerare următoarele situații: utilizatorii trebuie să reîmprospăteze constant pagina web pentru a vedea cele mai recente date; Sau să recuperezi (și să afișezi) date noi pe pagină implementând sondaje lungi, apoi poți lua în considerare folosirea SignalR pentru a face acest lucru. De exemplu: dashboard-uri și aplicații de monitorizare; Aplicații colaborative (de exemplu, mai multe persoane care editează documente simultan); Actualizări despre progresul jobului și formulare de prezentare în timp real, etc.
SignalR este potrivit și pentru tipuri noi de aplicații web care necesită actualizări de înaltă frecvență de la server, cum ar fi jocurile în timp real. Iată un exemplu bun: ShoorR.
SignalR oferă o API simplă pentru utilizatori care pot crea apeluri de procedură la distanță server-la-client (RPC) care pot fi accesate cu ușurință de pe partea serverului. Cod de rețea. SignalR include, de asemenea, conexiuni (de exemplu, evenimente de conexiune și deconectare) și gruparea conexiunilor.
SignalR poate gestiona automat conexiunile. Și îți permite să trimiți mesaje broadcast către toți clienții conectați, exact ca într-o cameră de chat. Desigur, pe lângă trimiterea în masă, poți trimite mesaje și unor clienți specifici. Conexiunea dintre client și server este persistentă, spre deosebire de protocolul HTTP tradițional, care necesită restabilirea conexiunii pentru fiecare comunicare.
SignalR suportă funcția "server push", unde codul serverului poate apela codul clientului în browser folosind apeluri de procedură la distanță (RPC) în locul cererilor folosite în prezent pe web – modelul corespunzător de procesare.
Aplicațiile SignalR pot fi extinse către mii de clienți folosind Service Bus, SQL SERVER sau Redis.
SignalR este open-source și poate fi accesat prin GitHub.
2. SignalR și WebSocket
ignalR folosește metoda de transport WebSocket - acolo unde este posibil. Și să comutăm automat la vechea metodă de transport (de exemplu, conexiune HTTP lungă). Cu siguranță poți scrie aplicația direct cu WebSockets, dar folosind SignalR vei avea mai multe funcționalități suplimentare fără să fie nevoie să reinventezi roata. Cel mai important, te poți concentra pe implementarea de business fără să te gândești la crearea unui cod compatibil separat pentru clientul vechi. SignalR vă permite, de asemenea, să evitați îngrijorarea cu privire la actualizările WebSocket, deoarece SignalR va continua să fie actualizat pentru a susține schimbarea metodelor de transport subiacente, oferind astfel o interfață de acces consecventă pentru aplicații din diferite versiuni de WebSockets.
Desigur, poți crea o soluție care folosește doar transportul WebSocket, iar SignalR oferă toate funcțiile de care ai nevoie pentru a-ți scrie propriul cod, cum ar fi revenirea la alte metode de transport și modificarea aplicației pentru implementări WebSocket mai noi.
3. Transport și întoarcere
SignalR este o abstractizare a tehnologiei de transport necesare pentru implementarea funcțiilor în timp real între clienți și servere. SignalR pornește mai întâi conexiunea cu HTTP și verifică dacă WebSocket-ul este disponibil – dacă da, actualizează la conexiunea WebSocket. WebSocket este cea mai ideală metodă de transmisie pentru SignalR deoarece folosește cel mai eficient memoria serverului, are cea mai mică latență și funcții de bază cuprinzătoare (cum ar fi comunicarea full-duplex între client și server), dar are și cele mai stricte cerințe: serverul trebuie să folosească sistemul de operare Windows Server 2012 sau Windows 8, și în același timp. .NET framework versiunea 4.5 și versiunile ulterioare. Dacă aceste cerințe nu sunt îndeplinite, SignalR va încerca să folosească o metodă alternativă de transmisie pentru conectare.
4. Livrare HTML5
Metoda de transport folosită depinde dacă browserul client suportă HTML5, altfel va fi folosită vechea metodă de transport.
WebSocket (dacă atât serverul, cât și browserul suportă WebSocket). WebSocket este singura modalitate de a stabili o conexiune bidirecțională adevărată și durabilă atât pe partea clientului, cât și pe cea a serverului. Desigur, WebSocket are și cele mai stricte cerințe: este suportat doar în cele mai recente versiuni ale IE, Chrome și FF și este implementat doar parțial în alte browsere precum Opera și Safari.
Serverul trimite evenimente, cunoscute și sub numele de EventSource (dacă browserul suportă evenimente de trimitere a serverului, practic toate browserele, cu excepția IE, suportă această funcție).
5. Transmisia cometelor
Următoarele tipuri de transport se bazează pe modelul aplicației web Comet, unde browserul sau clientul va menține o cerere lungă de conexiune HTTP, iar serverul poate trimite date către client fără o cerere explicită din partea acestuia.
Forever Frame (adică doar) Forever Frame va crea un IFrame ascuns care trimite o cerere către server care nu va fi finalizată. Serverul trimite apoi continuu scripturi către client și este executat imediat de client, adică o conexiune unidirecțională în timp real de la server la client. Conexiunea client-server folosește o conexiune diferită față de acea conexiune. De exemplu, o cerere HTML standard creează o nouă conexiune pentru fiecare dată trimisă.
Interogarea lungă Ajax nu creează o conexiune persistentă, ci interogează prin solicitări constante către server. Așteaptă răspunsul serverului și închide această conexiune la fiecare conexiune, apoi fă imediat o nouă cerere. Desigur, acest lucru va cauza o întârziere când conexiunea este resetată și reconectată.
Pentru informații despre metodele de transport suportate de diverse configurații, vezi Platforme suportate. (IE necesită 8 sau mai mult, celelalte browsere sunt versiunea curentă -1)
Procesul de selecție a metodei de transfer
Lista următoare arată cum SignalR decide ce tip să folosească pentru transmisie.
IE8 și versiunile anterioare, folosesc sondaje lungi.
Dacă JSONP este configurat (adică parametrul jsonp este setat pe true la conectare), folosește lung polling.
Dacă folosești o conexiune cross-domain (adică punctul final SignalR și pagina nu sunt în același domeniu), atunci folosește WebSockets dacă sunt îndeplinite următoarele condiții:
Clientul suportă Partajarea Resurselor Cross-Domain (CORS), vezi CORS la pentru detalii
Clientul suportă WebSocket
Serverul suportă WebSocket
Dacă oricare dintre condițiile de mai sus nu este îndeplinită, se folosește un sondaj lung. Pentru mai multe informații despre conexiunile între domenii, vezi Cum să stabilești conexiuni între domenii.
Dacă nu configurezi utilizarea JSONP și conexiunea nu este cross-domain, folosește WebSocket, desigur, cu condiția ca atât clientul, cât și serverul să suporte WebSocket.
Dacă clientul sau serverul nu suportă WebSockets, folosește serverul pentru a trimite evenimente.
Dacă serverul trimite un eveniment care nu este disponibil, folosește un Forever Frame.
Dacă Forever Frame nu este disponibil, folosește sondajul lung.
Transmisia monitorului
Poți vedea ce metodă de transport folosește aplicația ta activând logarea Hub și în consola browserului tău.
Pentru a permite logarea, adăugați următoarea comandă aplicației client:
nnection.hub.logging = adevărat;
6. Inspecție și transport:
Poți vedea ce metodă de transport folosește aplicația ta activând logarea Hub și în consola browserului tău. Pentru a permite logarea, adăugați următoarea comandă aplicației client:
nnection.hub.logging = adevărat;
$.connection.hub.logging = adevărat;
În IE, apasă F12 pentru a deschide uneltele de dezvoltare și apasă pe fila Console.
În Chrome, apasă Ctrl+Shift+J pentru a deschide consola
Observând logarea în consolă, poți vedea metoda de transmisie pe care o folosește SignalR.
7. Transport desemnat:
Negocierea metodei de transmisie necesită o anumită perioadă de timp și resursele serverului/clientului. Dacă mediul client este cunoscut, atunci metoda de transport poate fi specificată la inițierea conexiunii pentru a îmbunătăți performanța. Codul următor demonstrează utilizarea interogării lungi a Ajax direct la inițierea conexiunii dacă clientul este cunoscut că suportă orice alt protocol:
conexiunea.start({ transport: 'longPolling' });
Dacă vrei ca un client să negocieze transportul într-o anumită ordine, poți specifica ordinea în care se încearcă negocierea. Codul de mai jos arată cum să încerci să folosești mai întâi WebSockets și să folosești sondaje lungi imediat după eșec.
conexiune.start({ transport: ['webSockets','longPolling'] });
Constantele șirurilor specificate de utilizator sunt definite după cum urmează:
WebSockets
forverFrame
serverSentEvents
longPolling
8. Conexiuni și hub-uri API-ul SignalR include două modele de comunicație client-server: conexiuni persistente și hub-uri.
O conexiune reprezintă un punct final simplu pentru trimiterea unui singur mesaj, grupat sau difuzat. API-ul PersistentConnection (reprezentat de clasa PersistentConnection în codul .NET) oferă dezvoltatorilor acces direct la protocolul de comunicare de bază al SignalR. Dezvoltatorii care au folosit API-uri bazate pe conexiune, precum WCF, vor fi mai familiarizați cu modelul de comunicare a conexiunii.
Hub-urile sunt canale de comunicare bazate pe API, dar de nivel superior, care permit clienților și serverelor să apeleze metode direct între ele. SignalR face o treabă excelentă în gestionarea programării între mașini, permițând clienților să apeleze ușor metode pe server ca și cum ar fi apelate metode locale, și invers. Dezvoltatorii care au folosit AIP-uri bazate pe apeluri la distanță, precum .Net Remoting, vor fi mai familiarizați cu modelul hub. Folosind hub-ul, poți de asemenea să treci parametri puternic tipați către metode și să le legi de model.
Diagramă de arhitectură: Diagrama de mai jos arată relația dintre hub, conexiunea continuă și tehnologia de bază folosită pentru transport.
9. Cum funcționează hub-ul:
Când codul serverului apelează clientul, serverul va trimite un pachet care conține metoda de apelare și parametrii (când obiectul este folosit ca parametru de metodă, va fi serializat ca JSON pentru a fi trimis) către client. Clientul verifică apoi numele metodei primite și efectuează o căutare de potrivire în metoda definită de client, iar dacă potrivirea este reușită, metoda este executată și obiectul deeriarizat este folosit ca parametru de metodă.
Poți folosi instrumente precum Fiddler pentru a monitoriza execuția apelurilor de metodă. Imaginea următoare arată o metodă capturată din jurnalele lui Fiddler pentru a fi trimisă de la serverul SignalR către clientul browserului web. Metoda inițiată din hub se numește MoveShapeHub, iar metoda numită updateShape.
În acest exemplu, numele hub-ului este identificat cu parametrul "H", numele metodei este identificat cu parametrul "M", iar obiectul parametrului trimis metodei este identificat cu parametrul "A". Aplicația care a generat mesajul a fost implementată în tutorialul de comunicare în timp real de înaltă frecvență.
Alege un model de comunicare:
Majoritatea aplicațiilor folosesc API-ul hub-ului, care poate fi folosit în următoarele situații:
Trebuie să specifici formatul în care este trimis mesajul.
Dezvoltatorii preferă să folosească un model de mesagerie și programare în locul unui model de apeluri la distanță
Modelul de mesagerie este folosit în aplicații existente și este planificat să fie portat pe SignalR.
|
Postat pe 05.07.2017 10:21:40
|
|
|
|
Proprietarul