Komentáře k článku

Kometa přináší web v reálném čase

Real-time web (nebo též česky „web v reálném čase“) je podle odhadů analytiků „buzzwordem zítřka“. Budete se s ním setkávat čím dál víc, jak se postupy R-T webu budou stávat běžnějšími. Pojďme se podívat na jednu technologii, která je s realtime webem často spojována, a která stála např. za Google Wave.

Zpět na článek

29 komentářů k článku Kometa přináší web v reálném čase:

  1. pas

    P2P...

    Upřesnil bych, že odkazovaná technika P2P ve Flashi s tématem tohoto článku moc nesouvisí. Tam už nejde vůbec o komunikaci klient-server, ale klient-klient (a dokonce to už ani není nad TCP, ale nad UDP). Chcete-li uvést flashovou alternativu k webovým „push“ technologiím (tj. k web sockets či cometu), tak to je jednoduše obecná socketová TCP komunikace (založená na libovolném protokolu – XML, binární data, nebo třeba POP3, zkrátka cokoliv, co umí server servírovat). Ta byla k dispozici ve Flashi mnohem dříve než P2P.

  2. Misha

    lightstreamer.com

    Do přehledu dostupných řešení bych přidal lightstreamer.com, k dispozici je i free edition.

    1. yossarian

      Re: A pritom by stacilo, kdyby MS umel dodrzovat standardy.

      MIME typ, zacinajici x-, rozhodne NENI zadny standard, je to napsane i na wiki – vendor-specific rozsireni, ktere se lehce rozsirilo. Aneb, kdo chce psa bit, hul si vzdy najde, ze?

  3. Martin Prokš

    Internet != HTTP

    Nechápu, proč se dává takové absolutní rovnítko mezi TCP/HTTP a internet. A to i u lidí u kterých by jeden čekal větší znalosti. TCP/HTTP je přece protokol navržený k nějakému účelu. Tímto účelem je jednorázové jednosměrné doručení většího nepoškozeného objemu dat primárně ve struktuře HTML na základě krátkého požadavku klienta. Na jiné úlohy tu jsou jiné protokoly.
    Jestliže dnešní uživatelé mají čím dál silnější požadavek mít jediné uživatelské rozhraní (prohlížeč) pro velkou skupinu internetových služeb, pak je asi na čase se začít zamýšlet nad novým protokolem + strukturou dat a z toho vyplynou nové implementace serveru/ů a prohlížečů které nám nebudou házet tolik klacky pod nohy a budou tu s námi snad zase nějakou dobu. Přijde mi to mnohem správnější a smysluplnější cesta než postupně a nekoncepčně znásilňovat jeden konec řetězce TCP/HTTP/HTML jen pro to aby se na jednom místě doplnila funkcionalita, kterou by mělo zajišťovat zcela jiné místo. Je to typické lepení bez pořádného rozmyslu.
    Nebo udělat primárně revizi HTTP protokolu (na tom to asi v tuto chvíli stojí) a zamyslet se jestli je tak nutné ho stále přenášet po TCP, nebo jestli to nerozšířit i pro UDP, samozřejmě s dořešením následujících důsledků. Ale to je zase v podstatě vypracování nového protokolu, jen jinak maskovaného ale možná politicky snadněji prostaditelného u uživatelů. Viz jaké je třeba teď hype kolem HTML5.0.

    1. Martin MalýAutor příspěvku

      Re: Internet != HTTP

      Ano, to co píšete je logické a já s tím naprosto souhlasím. Ale co naděláte – realita je taková, že klientem je prohlížeč, a jakékoli pokusy o standardizaci aplikační platformy (co třeba AIR?) zatím naráží na argument „… ale prohlížeč je všude!“ Doba je zkrátka taková, že pokud se přijde na to, že by lidem v prohlížeči víc vyhovovalo UDP, tak se vymyslí, jak jej nasimulovat přes TCP, protože je to jednodušší, rychlejší a levnější (!) než všem říkat, že mají používat něco jiného. Může se nám to nelíbit (a nelíbí se nám to), ale je třeba o tom informovat, protože tudy jde, ať chceme nebo nechceme, vývoj, a chceme-li být praktickým magazínem, nemůžeme říct „toto je ideově pochybené, o tom psát nebudeme, to pro nás neexistuje“.
      Jasně že by bylo skvělé, kdyby tu byl Univerzální Síťový Klient, uměl plnohodnotný jazyk pro návrh UI a chovat se jako klient/server/P2P/at­d. A taky by bylo skvělé, kdyby se lidi měli rádi a nikde se neválčilo.

      1. pas

        Re: Internet != HTTP

        Není třeba vymýšlet novinky jako AIR (jeho význam pro offline aplikace rychle slábne s příchodem moderních browserů). Stačí nedémonizovat pluginové technologie, které zrovna v této komunikační oblasti doplňují to, co browserům chybí. Málokdo ví, že může v HTML udělat aplikaci bez HTTP, na bázi TCP nebo UDP, prostě přesně podle akademických představ. Při zachování všeho toho, na co jsou uživatelé zvyklí – běh v browseru, bezpečnost sandboxu, GUI v HTML (pokud nevyhovuje GUI ve Flashi, Silverlightu, apod.).
        Hlavní žába na prameni je jinde – u administrátorů firewallů. Což je důvod, proč i multiplayer flashové hry děláme s tou zatracenou kometou. :)

  4. BlackRider

    Takovej dlouhej clanek o takovy blbosti :)

    Teda nevim, ale kdyz chci, aby mi server porad neco posilal, tak ho proste nenecham zavrit spojeni a pokud spojeni spadne, tak ho obnovim. Proc kolem toho delat takovou vedu?

    1. Aleš Roubíček

      Re: Takovej dlouhej clanek o takovy blbosti :)

      Kolik takových otevřených spojení dokáže váš server držet?

      1. BlackRider

        Re: Takovej dlouhej clanek o takovy blbosti :)

        Tenhle argument sem moc nepochopil. Pro server je mnohem mensi zatez drzet otevrena neaktivni spojeni, nez neustale otevirat a zavirat spojeni kvuli heartbeatu…

        1. veros

          Re: Takovej dlouhej clanek o takovy blbosti :)

          Tak zkuste odpovědět na otázku: „Kolik otevřených spojení dokáže Váš webserver držet?“
          Běžný Apache blahé paměti na každé spojení potřeboval jednoho potomka a ten potřeboval nějaké megabajty paměti (odhadněme třeba 8 MB, a to při několika zapnutém PHP spíš podceňuju). Pokud máte server, který má 1024 MB RAM, tak mi to vychází na 128 otevřených spojení, což může být proklatě málo i pro lokální intranet.
          Jaká je situace s Apachem dnes, tak to netuším.
          Stačí tak?

          1. BlackRider

            Re: Takovej dlouhej clanek o takovy blbosti :)

            Nevim, kolik otevrenych spojeni dokaze muj webserver drzet. Nikdy sem na ten limit nenarazil…
            Proc se bavime o pametove nenazranosti Apache? Ostatne pokud nekdo chce vykon nepouzije PHP, ale aplikacni server bud samostatnej nebo komunikujici pres fcgi…

        1. MarSik

          Re: Takovej dlouhej clanek o takovy blbosti :)

          To nemá, ale s otevřením 300k socketů už má problém na úrovni OS. Jak s množstvím, portů, tak s množstvím otevřených „souborů“.

          1. BlackRider

            Re: Takovej dlouhej clanek o takovy blbosti :)

            Pri takovym poctu aktivnich uzivatelu, ale uz nikdo nebude pouzivat pouze jeden server. Ostatne typickym prikladem servisu s milionama otevrenych spojeni jsou IM servery jako ICQ, ktery sou tu uz pres deset let…

            1. jay

              Re: Takovej dlouhej clanek o takovy blbosti :)

              Nic ve zlém, ale proč s tím nepřišls dřív, že je to tak jednoduché. klukům v americe by to ušetřilo dost práce. Teď, když tím zabili tolik času, tak asi budou mrzutí.
              A to se jich tím zabývá dost (třeba vývojáři glassfishu) a žádného to nenapadlo :-))

              1. BlackRider

                Re: Takovej dlouhej clanek o takovy blbosti :)

                Ehm, co z toho, ze tohle pouziva ICQ uz 14 let si nepochopil? :)

                1. MarSik

                  Re: Takovej dlouhej clanek o takovy blbosti :)

                  Nepoužívá, resp ne erlang. Clustery samozřejmě ano. Na počet obsloužitelných spojení v ejabberd se můžete zeptat Pinkyho, má s tím na jabbim celkem zajímavé zkušenosti :)

                  Ale článek je o Comet a tam je to malinko o něčem jiném, protože klient neudržuje pořád jediné TCP spojení jako u IM. Posílá na rozdíl od IM mnoho požadavků a potřebuje hodně pomocných Comet spojení s tím, že bude zachovaný session tracking.

                  První (a jediný) mně známý web framework (a zrovna postavený na erlangu), který umí pracovat plně distribuovaně bez inteligence v load balanceru, je Nitrogen (nitrogenprojec­t.com) a bez hacků to umí až od verze 2, která je stará maximálně pár měsíců. A interně používá právě již zmíněný mochiweb nebo Yaws.

                  Každopádně se celkem těším na web sockets, už se objevují první vlaštovky.. bude snad konec kometám.

                  1. BlackRider

                    Re: Takovej dlouhej clanek o takovy blbosti :)

                    Ja mluvil obecne o velkym mnozstvi dlouho otevrenych TCP spojeni. Jedinej rozdil mezi „RT webem“ jak je popsanej v clanku a mezi ICQ je, ze komunikace ICQ je obousmerna po tom jednom spojeni, kdezto u „RT webu“ je komunikace po dlouhodobym spojeni pouze od serveru ke klientu a na opacnej smer se pouzivaj klasicky kratky HTTP requesty.

  5. dc

    poznamka

    Jedna poznamka, je rozmune alebo spravne nazyvat tuto temu zrovna web v realnom case ? OS aj aplikacie v realnom case su vecsinou o niecom inom a aj inak zamerane, tak predpokladam ze aj „real time web“ by malo byt nieco ine ako v podstate web kde klient-server si drzi spojenie, lebo v podste sa tu o to jedna.

    1. Martin MalýAutor příspěvku

      Re: poznamka

      Viz text: „Wikipedie dále upozorňuje na rozdíly proti známému pojmu „real-time computing“ – v real-time webu jde často o posílání krátkých zpráv, odkazů, statusů či podobných společenských PINGů. Pro lepší představu si lze real-time web představit jako implementaci chování instant messengerů či IRC v prostředí http://WWW.“ – ano, je to něco jiného, ale říká se tomu zkrátka real-time web. Můžeme tomu říkat třeba „web s instantním upozorněním“, ale nebudeme si rozumět.

      1. 100% Lenin

        Re: poznamka

        hm, a proč to olízávání servrovejch služeb nenechat na klientovi.
        As Is.
        Že by opět vítězila snaha o centralizaci všeho v Praze?

        1. avo

          Re: poznamka

          A to že sa nechodíš pýtať na centrálu pošty či mas niečo nové, ale nová pošta príde vždy za tebou sama do schránky je tiež dôsledok „snahy o centralizaci všeho v Praze“?
          Ta analogia je možno ironická, kritická a zabavná, ale aj úplne nepresná.
          Dôvodov je mnoho. Stačí sa pozreť na trendy moderných webov a požiadavky ktoré sa na ne kladú.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3308