Cometă (programare) - Comet (programming)

Cometa este un model de aplicație web în care o solicitare HTTPS de lungă durată permite unui server web să trimită date către un browser , fără ca acesta să solicite în mod explicit acest lucru. Cometa este un termen umbrelă , care cuprinde mai multe tehnici pentru realizarea acestei interacțiuni. Toate aceste metode se bazează pe caracteristici incluse implicit în browsere, cum ar fi JavaScript , mai degrabă decât pe pluginuri non-implicite. Abordarea Comet diferă de modelul original al web-ului , în care un browser solicită o pagină web completă la un moment dat.

Utilizarea tehnicilor Comet în dezvoltarea web este anterioară utilizării cuvântului Comet ca neologism pentru tehnicile colective. Cometa este cunoscută sub alte câteva nume, inclusiv Ajax Push , Reverse Ajax , Two-way-web , HTTP Streaming și HTTP server push printre altele. Termenul de cometă nu este un acronim, dar a fost inventat de Alex Russell în postarea sa din blogul din 2006, Comet: Low Latency Data for the Browser .

În ultimii ani, standardizarea și asistența pe scară largă a evenimentelor trimise de WebSocket și Server a făcut ca modelul Comet să fie învechit.

Istorie

Aplicații Java timpurii

Abilitatea de a încorpora applet - uri Java în browsere (începând cu Netscape Navigator 2 .0 în martie 1996) a făcut posibilă comunicarea susținută în două direcții, utilizând un socket TCP brut pentru a comunica între browser și server. Această priză poate rămâne deschisă atâta timp cât browserul se află la documentul care găzduiește applet-ul. Notificările evenimentelor pot fi trimise în orice format - text sau binar - și decodate de applet.

Primul cadru de comunicare browser-browser

Prima aplicație care utilizează comunicații de la browser la browser a fost Tango Interactive, implementată în 1996–98 la Centrul de Arhitecturi Paralele de Nord-Est ( NPAC ) de la Universitatea Syracuse folosind finanțare DARPA . Arhitectura TANGO a fost brevetată de Universitatea Syracuse. Cadrul TANGO a fost utilizat pe scară largă ca instrument de educație la distanță. Cadrul a fost comercializat de CollabWorx și utilizat într-o duzină de aplicații de comandă și control și instruire din Departamentul Apărării al Statelor Unite.

Primele aplicații Comet

Primul set de implementări Comet datează din 2000, cu proiectele Pushlets , Lightstreamer și KnowNow. Pushlets , un cadru creat de Just van den Broecke, a fost una dintre primele implementări open source. Pushlet-urile s-au bazat pe servlet-uri Java de pe server și pe o bibliotecă JavaScript pe partea de client. Bang Networks - un start-up din Silicon Valley susținut de cofondatorul Netscape , Marc Andreessen  - a avut o încercare bogată de a crea un standard push în timp real pentru întregul web.

În aprilie 2001, Chip Morningstar a început să dezvolte un server web bazat pe Java (J2SE) care folosea două socketuri HTTP pentru a menține deschise două canale de comunicații între serverul HTTP personalizat pe care l-a proiectat și un client proiectat de Douglas Crockford ; a existat un sistem demo funcțional din iunie 2001. Serverul și clientul au folosit un format de mesagerie pe care fondatorii State Software, Inc. l-au aprobat să inventeze ca JSON în urma sugestiei lui Crockford. Întregul sistem, bibliotecile client, formatul de mesagerie cunoscut sub numele de JSON și server, au devenit Cadrul de aplicații de stat, ale cărui părți au fost vândute și utilizate de Sun Microsystems, Amazon.com, EDS și Volkswagen.

În martie 2006, inginerul software Alex Russell a inventat termenul Cometă într-o postare pe blogul său personal. Noul termen a fost o piesă pe Ajax ( Ajax și Comet fiind ambii curățători obișnuiți în SUA).

În 2006, unele aplicații au expus aceste tehnici unui public mai larg: aplicația de chat bazată pe web multi-protocol Meebo a permis utilizatorilor să se conecteze la platformele de chat AOL , Yahoo și Microsoft prin browser; Google a adăugat chat bazat pe web la Gmail ; JotSpot , un startup de când a fost achiziționat de Google, a creat editare de documente colaborative în timp real bazată pe Comet. Au fost create noi variante de comete, cum ar fi cadrul JSF ICEfaces bazat pe Java (deși preferă termenul " Ajax Push "). Alții care anterior folosiseră transporturi bazate pe applet Java au trecut în schimb la implementări JavaScript pure.

Implementări

Aplicațiile comete încearcă să elimine limitările modelului web pagină cu pagină și interogarea tradițională oferind o interacțiune susținută bidirecțională, utilizând o conexiune HTTP persistentă sau de lungă durată între server și client. Deoarece browserele și proxy-urile nu sunt proiectate având în vedere evenimentele serverului, au fost dezvoltate mai multe tehnici pentru a realiza acest lucru, fiecare cu avantaje și dezavantaje diferite. Cel mai mare obstacol este specificația HTTP 1.1, care afirmă „această specificație ... încurajează clienții să fie conservatori atunci când deschid conexiuni multiple”. Prin urmare, menținerea unei conexiuni deschise pentru evenimente în timp real are un impact negativ asupra utilizabilității browserului: browserul poate fi blocat de la trimiterea unei noi solicitări în timp ce așteaptă rezultatele unei cereri anterioare, de exemplu, o serie de imagini. Acest lucru poate fi rezolvat prin crearea unui nume de gazdă distinct pentru informații în timp real, care este un alias pentru același server fizic. Această strategie este o aplicație de partajare a domeniului.

Metodele specifice de implementare a Cometei se încadrează în două categorii majore: streaming și sondaje lungi .

Streaming

O aplicație care utilizează streaming Comet deschide o singură conexiune persistentă de la browserul client la server pentru toate evenimentele Comet . Aceste evenimente sunt tratate incremental și interpretate de partea clientului de fiecare dată când serverul trimite un eveniment nou, niciuna dintre părți nu închide conexiunea.

Tehnicile specifice pentru realizarea streamingului Comet includ următoarele:

Iframe ascuns

O tehnică de bază pentru aplicația web dinamică este utilizarea unui element HTML iframe ascuns (un cadru în linie , care permite unui site web să încorporeze un document HTML în altul). Acest iframe invizibil este trimis ca un chunked bloc, pe care îl declară în mod implicit ca infinit lung (uneori numit „ pentru totdeauna frame“). Pe măsură ce apar evenimente, iframe-ul este umplut treptat cu script etichete, conținând JavaScript pentru a fi executat în browser. Deoarece browserele redau paginile HTML în mod incremental, fiecare script etichetă este executată pe măsură ce este primită. Unele browsere necesită o dimensiune minimă specifică a documentului înainte de a începe analiza și executarea, care poate fi obținută prin trimiterea inițială a 1-2 kB de spații de umplere.

Un avantaj al metodei iframes este că funcționează în fiecare browser comun. Două dezavantaje ale acestei tehnici sunt lipsa unei metode fiabile de tratare a erorilor și imposibilitatea de a urmări starea procesului de apelare a cererii.

XMLHttpRequest

Obiectul XMLHttpRequest (XHR), un instrument utilizat de aplicațiile Ajax pentru comunicarea browser-server, poate fi, de asemenea, apăsat în serviciu pentru mesaje server-browser Comet, generând un format de date personalizat pentru un răspuns XHR și analizând fiecare eveniment folosind browser- JavaScript lateral; bazându-se doar pe browserul care declanșează onreadystatechange apelul de fiecare dată când primește date noi.

Ajax cu sondaj lung

Niciunul dintre transporturile de streaming de mai sus nu funcționează pe toate browserele moderne fără efecte secundare negative. Acest lucru îi obligă pe dezvoltatorii Comet să implementeze mai multe transporturi complexe de streaming, comutând între ele în funcție de browser. În consecință, multe aplicații Comet folosesc sondaje lungi, care sunt mai ușor de implementat din partea browserului și funcționează, cel puțin, în fiecare browser care acceptă XHR. După cum sugerează și numele, interogarea îndelungată impune clientului să interogheze serverul pentru un eveniment (sau un set de evenimente). Browserul face o cerere în stil Ajax către server, care este menținută deschisă până când serverul are date noi de trimis către browser, care sunt trimise browserului într-un răspuns complet. Browserul inițiază o nouă solicitare de sondare lungă pentru a obține evenimente ulterioare. IETF RFC 6202 „Probleme cunoscute și cele mai bune practici pentru utilizarea sondajului lung și a fluxului în HTTP bidirecțional” compară sondajul lung și fluxul HTTP. Tehnologiile specifice pentru realizarea unui sondaj îndelungat includ următoarele:

XMLHttpRequest sondaj lung

În cea mai mare parte, sondajul XMLHttpRequest funcționează ca orice utilizare standard a XHR. Browserul face o cerere asincronă a serverului, care poate aștepta ca datele să fie disponibile înainte de a răspunde. Răspunsul poate conține date codificate (de obicei XML sau JSON ) sau Javascript pentru a fi executate de client. La sfârșitul procesării răspunsului, browserul creează și trimite un alt XHR, pentru a aștepta următorul eveniment. Astfel, browserul păstrează întotdeauna o cerere remarcabilă cu serverul, pentru a fi răspuns la fiecare eveniment.

Etichetare script lung sondaj

În timp ce orice transport Comet poate fi făcut să funcționeze pe subdomenii , niciunul dintre transporturile de mai sus nu poate fi utilizat pe diferite domenii de nivel secundar (SLD), datorită politicilor de securitate ale browserului concepute pentru a preveni atacurile de scriptare între site-uri . Adică, dacă pagina web principală este servită dintr-un SLD, iar serverul Comet este situat într-un alt SLD (care nu are activată partajarea resurselor încrucișate ), evenimentele Comet nu pot fi utilizate pentru a modifica HTML și DOM din pagină, folosind acele transporturi. Această problemă poate fi evitată prin crearea unui server proxy în fața uneia sau a ambelor surse, făcându-le să pară că provin din același domeniu. Cu toate acestea, acest lucru este adesea nedorit din motive de complexitate sau performanță.

Spre deosebire de iframe sau obiecte XMLHttpRequest, script etichetele pot fi îndreptate către orice URI , iar codul JavaScript din răspuns va fi executat în documentul HTML curent. Acest lucru creează un risc potențial de securitate pentru ambele servere implicate, deși riscul pentru furnizorul de date (în cazul nostru, serverul Comet) poate fi evitat folosind JSONP .

Un transport Comet cu interogare lungă poate fi creat prin crearea dinamică a script elementelor și setarea sursei acestora la locația serverului Comet, care apoi trimite înapoi JavaScript (sau JSONP) cu un eveniment ca sarcină utilă. De fiecare dată când cererea de script este finalizată, browserul deschide una nouă, la fel ca în cazul de sondare XHR lung. Această metodă are avantajul de a fi cross-browser, permițând în același timp implementări pe mai multe domenii.

Alternative

Tehnologiile native pentru browser sunt inerente termenului de cometă. Încercările de a îmbunătăți comunicarea HTTP non-sondaj au venit din mai multe părți:

  • HTML 5 Proiectul de caietul de sarcini produs de Hypertext Application Group Web Tehnologie de lucru (WHATWG) precizează în așa - numitele evenimente trimise de server , care definește o nouă interfață JavaScript EventSource și un nou tip MIME text/event-stream . Toate browserele majore, cu excepția Microsoft Internet Explorer, includ această tehnologie.
  • Proiectul de lucru HTML 5 WebSocket API specifică o metodă pentru crearea unei conexiuni persistente cu un server și primirea mesajelor printr-un onmessage apel invers.
  • Protocolul Bayeux de către Fundația Dojo . Lasă la loc transporturile specifice browserului și definește un protocol de nivel superior pentru comunicarea între browser și server, cu scopul de a permite reutilizarea codului JavaScript din partea clientului cu mai multe servere Comet și de a permite același server Comet să comunice cu mai multe implementări JavaScript de partea clientului. Bayeux se bazează pe un model de publicare / abonare, astfel încât serverele care acceptă Bayeux au încorporat publicarea / abonarea.
  • BOSH Protocolul de standardele fundație XMPP. Emulează un flux bidirecțional între browser și server utilizând două conexiuni HTTP sincrone.
  • Obiectul JSONRequest, propus de Douglas Crockford , ar fi o alternativă la obiectul XHR.
  • Utilizarea pluginurilor, cum ar fi applet-urile Java sau Adobe Flash proprietar (folosind protocolul RTMP pentru transmiterea de date către aplicațiile Flash). Acestea au avantajul de a lucra identic pe toate browserele cu pluginul adecvat instalat și nu trebuie să se bazeze pe conexiunile HTTP, ci dezavantajul de a cere instalarea pluginului
  • Google a anunțat un nou API Channel pentru Google App Engine , implementând un API de tip Comet, cu ajutorul unei biblioteci JavaScript client din browser. Acest API a fost învechit.

Vezi si

Referințe

linkuri externe