ugrás a tartalomhoz

Az AJAX elavult, itt a Comet

Bártházi András · 2006. Már. 6. (H), 22.55
Természetesen a cím hülyeség, mindazonáltal Alex Russell által közzétett új megközelítést tekintve itt egy új látásmód az AJAX alapon működő weblapokhoz, Comet néven. S hogy mi is ez? "Definíció szerint" az AJAX technikát alkalmazva a böngésző a szerver fele kéréseket intéz, melyekre aztán választ kap. A Comet ezt fordítja meg, s lehetővé teszi, hogy a szerver küldjön információt a kliens fele. Azért persze ennek ára van.

Az AJAX működését szemléltető diagramot megnézve látható, hogy a böngészőből indulnak az események, egy kérést küld a szerver felé, majd pedig választ kap onnan. Ezt a lehetőséget biztosítja az XMLHTTPRequest objektum, s kb. ezt a megoldást ismertük eddig. Illetve van egy olyan lehetőség is, amit kevésbé használunk, de már nagyon régóta rendelkezésünkre áll, ez pedig a keep alive, amikor a szerver egy kérésre a választ folyamatosan (inkrementálisan) küldi a böngésző felé.

A Comet elképzelés a háttérben szintén XMLHTTPRequest objektumot használ, megnyit egy kapcsolatot, s vár a válaszra a szervertől. Az ilyen irányú megoldás előnye ott mutatkozik meg, ahol jellemzően a szerver oldalról jön több információ, s az sem gyakran, hanem esetileg. Jellemzően ilyen egy chat alkalmazás, vagy más PUSH megoldások. Ha nem ilyen alkalmazást írunk, korántsem kell azonban elfelejtenünk a "szokványos" AJAX megoldásokat.

A bevezetőben is említettem, hogy a Cometnek ára van: a kliensek folyamatos kapcsolatot tartanak fenn a szerverrel, azaz annyi webszerver (Apache) thread lesz, amennyi kliens látogat meg minket. Ez egy látogatottabb oldalnál elég szépen meg tudja fektetni a webszervert. Persze nem olyan nehéz megtalálni a megoldást valamilyen speciális szerver futtatásának személyében, melyek pont ilyen célokra készültek.

Alex Comet nevet felvető bejegyzéséből, illetve a hozzászólásokból persze ennél sokkal több is kiderül.
 ■
1

Végre!

janoszen · 2006. Már. 7. (K), 08.18
Az internet koncepciójában régen szerepelnek már a PUSH kérések, de biztonsági okokból eddig még senki nem valósította meg őket. Végre. De mondjuk, ha nem time critical a dolog, akkor lehet percenként egy kérést végrehajtani és ezzel csökkenteni a threadek számát.
2

<Nincs cím>

Anonymous · 2006. Már. 7. (K), 09.38
A percenkénti lekéréssel viszont pont a dolog lényege veszik el és ott vagyunk mint egy sima AJAX-os alkalmazásnál
3

Nem is igaz!

Anonymous · 2006. Már. 8. (Sze), 10.51
Az Ajax egy jó focicsapat, az Interrel is 2-2-t játszott!:)
4

<Nincs cím>

saxus · 2006. Már. 8. (Sze), 22.03
Hasonlót már láttam, úgy hívják CGI:IRC. Egy web-böngészőben futó IRC kliens volt, ott is folyamatosan tartotta a kapcsolatot a szerver a böngészővel, szóval mint a hírben is volt, nem új dolog.
5

Nem ez a kérdés

Bártházi András · 2006. Már. 8. (Sze), 22.57
Nem az az újdonság, hogy folyamatosan lehet tartani a kapcsolatot, hanem az, hogy a szerver szól le a kliensnek, úgynevezett push megoldással. Persze még pontosabban ez sem újdonság, csupán a megközelítés módja, és az, hogy nevet adtunk neki (ahogyan az AJAX sem volt újdonság, mégis a névadással tört be a köztudatba).

-boogie-
6

Példa

prezi · 2006. Már. 9. (Cs), 10.10
Na igen, de sose láttam még ilyen megvalósításnak a forrását (sajnos), pedig a Keepalive-ot régóta tudja az apache.

Tulajdonképpen nem küldök eof-ot? De ha jól értem nem erről szól a móka (ez elég triviális), hanem kiküldöd a különböző dolgaidat, eof-ot is küldesz, de a szerver és a böngésző nem dobja el a kapcsolatot, és várja a köv kérést, vagy ő küld ki újat adatot. Mondjuk ez utóbbit elég nehézkes lehet php-val megvalósítani...
7

semmi extra

Hodicska Gergely · 2006. Már. 9. (Cs), 14.03
Keepalive-ot régóta tudja az apache

Ennek nem sok köze van ehhez. ;) Itt a szerver nem zárja be a kapcsolatot.

A dolog amúgy tök egyszerű, van egy végetelen ciklusod (ami mondjuk adott szekvenciára kilép, meg figyeli, hogy a user ne csukta-e be a böngészőt). Ebben monjduk (egyszerű chat) egy fájlt figyelgetsz, és ha van benne új sor, akkor azt elküldöd a böngészőnek.
Ennek formája úgy nézhet ki, hogy egy JS kódrészletet küldesz neki. Ezt a böngésző megkapja, értelmezi, a JS kód meg olyan, hogy ezt az egy sort odacsapja egy textareahoz.

Egy dologra kell figyelni, hogy pl. IE is csak akkor áll neki értelmezi a kapott adatokat, ha az elér egy valamekkora mennyiséget. Erről terjengenek városi legendák (pl. 255 byte kell legyen minimum), de pontos adatot nem tudok. Ha ennél rövidebb a küldendő kód, akkor még hozzá kell csapni némi white space-t.

És persze szerveroldali output_bufferingre is figyelni kell, hogy nehogy az szivasson meg.


Felhő
8

Csak azt nem tudom

Anonymous · 2006. Már. 9. (Cs), 16.56
Hogy egy PHP-s alkalmazásban ezt hogy valósítod meg?
Végtelen ciklus megeszi a procidat, vagy ha sokat vársz egy iterációkor, akkor meg már mehetne sima ajax-szal. :)

Mondjuk vársz egy MySQL lock feloldásra, ennél jobb nem jut eszembe.

Ezek hekkelt megoldások, és a mostani tehnológiával azok is maradnak.
szerintem.
9

máshol nem?

Hodicska Gergely · 2006. Már. 11. (Szo), 10.58
Végtelen ciklus megeszi a procidat

Más programnyelvekben is egy végtelen ciklus megeszi a procit, ezért szoktak adott esetben valamennyi sleepet tenni bele.


Felhő