Kispad

Kispad: közös blog
4230 cikk, 53915 hozzászólás
Szerzők | Tudnivalók | Feedek


Jön a valódi webstreaming

eszpee cikke a Torokgeek rovatból, 2006. szeptember 6. szerda, 20:57 | 22 hozzászólás

Ejj, azok a régi szép idők, amikor még modemről offline mentve böngészgettem a frissen formálódó HTML 4 specifikáció változásait az előző elmentett verziómhoz képest... azóta lassan eltelt tíz év, és nagyon finoman fogalmazok, ha azt mondom, nem vagyok kimondottan naprakész az újdonságok terén. Most viszont (ezt a most-ot persze az előző mondat erősen árnyalja) valami olyan dolog történik, ami alapjaiban változtathatja meg a webet.

Bárki, aki kicsit is foglalkozott webfejlesztéssel, alap axiómának vette, hogy a HTTP protokoll, és az egész web, ami azon fut, egy "kérdés-válasz" csatorna, ahol a kliens szól a szervernek, hogy kérne valamit, a szerver erre (jó esetben) elküldi, majd viszontlátásra, találkozunk a következő lekérésnél, legyen az szöveg, kép, bármi. Nincs kézenfekvő lehetőség a kliens megtartására, folyamatos friss adatok küldésére, stb. - ami van, az mind workaround, a cookie-alapú sessionkezeléstől az AJAXos másodpercenkénti megszólításig minden.

Pontosabban workaround volt - egy majdnem egyhetes Opera-közeli post ébresztett rá ugyanis, hogy a WHATWG csoport többek között ezt az axiómát készül felrúgni, olyannyira, hogy például az Opera 9 már teljesíti is a specifikáció ezen részét.

Valójában persze nem atomfizika a dolog, egyszerűen meghatároztak egy szabvány kommunikációs módszert, amivel a szerver által folyamatosan küldött adatokat DOM események formájában elkaphatjuk - és kész is, ennyi az egész, amint az a kis példachat oldalról látszik is.

Rohan a világ vonalon illesszetek be egy adekvát közmondást.

» Ugorj a hozzászóló ablakhoz

Megosztások Facebookon

Eddigi hozzászólások (22)

1

Adi, 2006. szeptember 6. szerda, 23:08 (#)

A szabványt nem olvastam el, van benne valami ésszerű timeout a kapcsolatbontásra? Ellenkező esetben "imádni" fogják az Apache-ot üzemeltetők, amikor a connection pool betelik. :))

2

Author Profile Page stsmork, 2006. szeptember 7. csütörtök, 07:54 (#)

Izé...miért is változtatja ez meg alapjaiban a webet? Konkrétan: mi az, amit a "push protocol" megléte nélkül eddig nem tudtál (igaz, kicsit körülményesebben) leprogramozni? Illetve, mi az a drámai változás, amit a mezei felhasználók hamarosan látni fognak, és amire enélkül soha nem kerülhetne sor?

3

Author Profile Page Karaj, 2006. szeptember 7. csütörtök, 12:49 (#)

User szemszögből nincs változás szerintem, viszont nagy mértékben tehermentesíti a szervereket. Én nem érzem ezt drámai változásnak, de határozottan pozitív dolog.

Trackback: http://magyaropera.blog.hu/2006/09/04/ajax_erosit_az_opera

4

Author Profile Page Karaj, 2006. szeptember 7. csütörtök, 16:20 (#)

Csináljatok webstreaminges widgetet vagy oldalt vasárnapig, és kaptok egy Operás pólót. Kihagyhatatlan ajánlat :)

http://magyaropera.blog.hu/2006/09/07/opera_polo_minden_uj_sse_widgetert

5

Boca, 2006. szeptember 7. csütörtök, 17:23 (#)

Hát igen, a http nem véletlenül stateless és ennek megvannak az előnyei is.
Állandó kapcsolatokat fenntartani több nagyságrenddel nagyobb erőforrást igényel sztm.
És miért nem elég jó köztes megoldás a keepalive?

6

Author Profile Page eszpee, 2006. szeptember 7. csütörtök, 17:26 (#)

Boca, a keepalive-on küldött adatot egy javascript eventtel el tudod kapni? Vagy én nem értem a kérdést...

7

Boca, 2006. szeptember 7. csütörtök, 17:38 (#)

A keepalive-on küldött adatok a kliens szempontjából ugyanolyan külön http kéréseknek látszanak, mint a keepalive előtti időkben (HTTP1.0). A válasz tehát igen.
Amennyire tudom, a brózer keepalive esetén nem zárja le a kapcsolatot, így a további kérések a szerver felé nem igénylik új kapcsolat nyitását. Ha pongyolán vagy tévesen fogalmaznék, akkor majd kijavítanak, remélem, mert én így tudom...

8

Boca, 2006. szeptember 7. csütörtök, 17:39 (#)

More info: http://en.wikipedia.org/wiki/Http_protocol#Persistent_connections

9

Author Profile Page eszpee, 2006. szeptember 7. csütörtök, 17:43 (#)

OK, értelek, akkor visszatérve a "miért nem jó köztes megoldás a keepalive" kérdésre: ennek semmi köze a témához. :)

Vegyük a címoldali kispad rádió dobozunkat, ez jelenleg úgy működik, hogy amíg valahol meg van nyitva a kispad.hu, az 5-10 másodpercenként (nem emlékszem a pontos értékre) odaszól a szervernek, hogy új számot játszunk-e már, vagy még mindig ugyanaz szól. Spórolok ugyan annyit, hogy http HEAD kérésből eldöntöm, mi a helyzet, de lássuk be, hogy ez rengeteg felesleges kérést jelent.

Ha minden böngésző támogatni fogja majd ezt a kiegészítést, akkor sokkal egyszerűbb lesz a dolgom: a szerver küldi a kliensnek az új szám információit, az meg elkapja és kirakja az oldalra. Kisebb adatforgalom, kisebb gányolás.

10

Author Profile Page NagyGa1, 2006. szeptember 7. csütörtök, 18:03 (#)

Adalék:
folyamatos kapcsolat meg tud szakadni, még a polling elég robosztus ebből a szempontból. Ok, lehet olyan az új szabvány hogy ha megszakadt akkor újraépít és queuez.

11

Boca, 2006. szeptember 7. csütörtök, 18:53 (#)

Eszpee, azért nem állítanám magabiztosan, h nincs köze a kérdéshez.
Az ugye megvan, hogy a te konkrét példád esetében a 2 megoldás közt mindössze az a különbség, h pull vagy push; te kéred le időközönként az eredményt, vagy a szerver küldi.
Minden más körülmény azonos, ugyanis ha keepalive-val kérdezel a jelenlegi megoldásban, akkor a rövid időközök miatt már most is van állandó kapcsolat a szerver és kliens közt, ahogy a streaming esetben is lenne.
Ugyanakkor push technikát már most is használhatnál, ha az a problémád, h a pull sok felesleges forgalmat generál.
Azt értem, h az új technika 2 dolgot csinál: állandó kapcsolat és push, ezért a kérdés is 2 részből áll, de mindkét részt implementálhatod ma is, platformfüggetlenül.
Ennek fényében túlzás valami forradalmi dologról beszélni. ;)

12

Author Profile Page eszpee, 2006. szeptember 7. csütörtök, 19:17 (#)

Boca, hogyan használhatnék pusht?

13

Boca, 2006. szeptember 8. péntek, 10:51 (#)

Eszpee, sztm nézz utána a neten, hogyan kell.
Ha konkrétan tudnám, segítenék, de sajnos nem tudom, mert még nem volt rá szükségem.

14

Author Profile Page eszpee, 2006. szeptember 8. péntek, 10:58 (#)

Boca, én állítom, hogy nem megoldható, így felesleges dolgokra nem pazarlom az időmet - de persze készségesen elnézést kérek tévedésemért, ha mutatsz egy push példát. :)

15

Boca, 2006. szeptember 8. péntek, 12:27 (#)

Eszpee, ezzel cáfolod a push technika létét. Ha jól értem.
Nem kell a gyakorlatban megcsinálnod, elég, ha elvi szinten elismered, hogy a cikked 2. bekezdése tévedésen alapszik, ezért nem igaz. Emiatt az én személyes következtetésem az, h egy push alapú http1.1 megoldás semmivel sem zabál több erőforrást, mint a most formálódó, Opera-közelinek mondott technika. A gyakorlati nehézségeiről ugye nem tudunk mondani semmit, mert egyikünk se tud egyikről sem példát mutatni, de ez sose volt akadálya egy kis vitának. ;)
Az én értelmezésemben a webstreaming fogalom teljesen analóg a push-sal, de szívesen látnék akár csak elméleti okfejtésként látható ellenpéldát.
Nem tanulmányoztam olyan szinten a fenti linkeket, h ki merjem jelenteni, h ez az operás kezdeményezés semmi újat nem nyújtana a jelenleg elérhető technológiákhoz képest, de 15 komment után se látom jelét, h ez egy forradalmi újítás lenne.
Amúgy nyugodtan hátra is dőlhetünk, mert ha elég könnyen ad majd klassz megoldást valami problémára, akkor biztosan utat tör majd magának.

16

yaanno, 2006. szeptember 8. péntek, 13:06 (#)

Boca: ha megnézed a specifikációt, abból kiderül, hogy a dolognak vajmi kevés köze van az Operához; ha jól láttam, az Opera community-ben tevékenykedő emberek készítették ezt az alkalmazást, amit eszpee említett; a post akkor is megállná a helyét, ha az Operáról egy árva hang se szólt volna. Ahhoz, hogy megállapítsuk, melyik visz el több erőforrást, benchmarking kell; erről pl. nem hallottam még, de utánanézek.

17

yaanno, 2006. szeptember 8. péntek, 13:11 (#)

Bocsánat, helyesbítek: a WHATWG != Opera, de pl. http://www.hixie.ch/specs/ az Operát említi; hm, ez most akkor nem vili :)

18

Boca, 2006. szeptember 8. péntek, 14:18 (#)

Yaanno, igazad van, ezért szándékosan fogalmaztam úgy, h Opera-közelinek mondott :)
Egyébként az Opera-közeli kifejezés szerepel a cikkben is, de a kifogásolt bekezdés helyessége nem ezen áll vagy bukik, mint ahogy a technika létjogosultsága sem.

19

Forsage, 2006. szeptember 8. péntek, 14:46 (#)

Netscape's Server Push (nem pedig client pull) néven volt ilyen a '90-es évek végén, webcam meg ilyesmi célokra. Nem igazán volt átütö sikere :)

Tesztoldal:

http://www.uark.edu/~wrg/netscape/push.html

Firefox alatt müxik, IE 6.0 alatt nem.

20

Author Profile Page eszpee, 2006. szeptember 8. péntek, 15:51 (#)

Boca, mondd, hogy nem a Forsage által linkelt "megoldásra" gondoltál...

21

Boca, 2006. szeptember 8. péntek, 22:17 (#)

Nekem tök jól működik az alternatív brózeremben :)

A főoldali applettel kapcsolatos kérdésemet magánban teszem fel.

22

kondi, 2006. szeptember 11. hétfő, 10:32 (#)

A keep-alive önmagában nem elég, kell hozzá chunk encoding es úgy már megoldható a push a jelenlegi eszközökkel.
Vagy rejtett flash objektum az oldalon, ami nyit egy xmlsocket-et es az ondata esemeny JS-t hiv meg.


Hozzászólsz?

Igen

Hozzászólást csak névvel együtt fogadunk el. Ha linket írsz be, akkor előtte és utána hagyj egy szóközt, főleg akkor, ha zárójelbe teszed.


Az oldal tetejére | Szerzők, tudnivalók, feedek | sesblog és Kispad © 2003-2010 ervin, eszpee, stsmork