Dotaz: Objektový návrh aplikace klient-server

[ja_kral_ll]

Ahoj,

jak by jste navrhli aplikaci kde jedno vlákno sosá data ze vzdáleného serveru a tyto data v reálném čase zprostředkuje klientům která se na tuto aplikaci připojí ?

Jedná se o videostream kde se skrz tenkou linku tahá jeden proud videa který se pak nabídne klientům na serveru který se na server připojí kde je už linka dost silná na to aby obsloužila dost klientů.

Zkoušel jsem pokus kdy se při každém přijatém kusu dat zavolají všechna vlákna klientů že přišla nová data a ať je zašlou klientům. Je to ale neúnosné, procházet ArrayList s vlákny klientů a spouštět na těchto vláknech metodu které předám jako parametr nově nasosaná data je hrozně pomalé.

Chce to vymyslet něco kdy se budou data sama dotazovat zda už nejsou nová data nasosaná. Máte s něčím podobným zkušenosti ?

Díky

Odpovědi

[Messa]

Nějakou kolekci (prostě nějaký objekt), kam to stahující vlákno bude ukládat data a ostatní vlákna se do ní dívat, zda není něco nového?

Jinak celá věc by šla řešit bez vláken, pollováním. Především, pokud tam není nějaké překódovávání dat apod. Ale to je asi o něco těžší naprogramovat.

[vbar]

Nevím jestli je zrovna ArrayList z jazyka vhodného pro aplikace omezené výkonem I/O (jinými slovy C/C++), ale kopírování na úrovni aplikace (síťovou komunikaci systém samozřejmě zkopírovat musí, aspoň pokud má zůstat TCP/IP) se jistě dá omezit v každém jazyce - stačí ty přicházející data cpát do nějakého globálu a synchronizovat standardními technikami. Data se sama dotazovat asi nebudou - mohou se dotazovat ta vlákna pro klienty, ale obecně se poll pokládá za méně efektivní než signalizace (konkrétní program samozřejmě může optimalizovat lecos, ale větší efektivitě pollu bych neuvěřil dokud bych jí neuviděl, a možná ani pak ne). Taky by možná stálo za úvahu nebudit všechna vlákna kvůli každému přijatému paketu, ale to už je spíš třešnička na dortu...

[ja_kral_ll]

Data nacpat do kolekce jsem zkoušel, je ale problém zjišťovat jestli se data změnila, pokud totiž základní jednotka bude byte tak je dost velká pravděpodobnost že že dva byty za sebou budou stejné. Šlo by data nacpat do do nějakého většího bloku abych data nemusel rozesílat tak často, otázka je co na to řekne videopřehrávač u klienta když mu data budou chodit jednou za čas ve velkých balících.

Pokud se tedy budou vlákna dotazovat za klienty tak jak budou zjišťovat zda už se načetla nová data ? Inkrementovat nějaký čítač se mi zdá zvrhlost, ale taky by to možná šlo. Taky je problém na jak dlouho mají vlákna spát než se budou dotazovat na nová data aby neprospaly změnu a zase se neptali zbytečně často.

[Messa]

Cože, tys to video chtěl posílat po bajtech?

Inkrementovat čítač mi přijde jako celkem dobré řešení. Video data ukládat do nějakého cyklického bufferu, pamatovat si, jaký offset (jakou hodnotu) má poslední blok dat, každé vlákno si pak bude pamatovat, co už klientovi poslalo...

Jak dlouho mají vlákna spát? To tam chceš mít sleep ... zjisti, jestli je něco nového, ne ... sleep ... atd.? Za to bys v programování zápočet nedostal :) od toho jsou synchronizační prostředky.

[ja_kral_ll]

Teď to tahám z frameworku kde to konvertuju po bytech, nějaký bufferování jdu řešit až teď.

Prubnu s tim čítačem a uvidíme.

Zápočet jsem dostal za mnohem větší čuňárnu :D

[dustin]

Nijak jsem to nestudoval, ale co třeba se podívat, jak jsou dělané http://code.dogmap.org/fdtools/multitee/ nebo http://multipipe.sourceforge.net/ ?

[ja_kral_ll]

To zní dobře, mrknu na to

[Filip Jirsák]

Řekl bych, že problémy budou úplně někde jinde. Za prvé bych si dal pozor na to, zda se data pro každého klienta nekopírují (případně několikrát). Pak bych se také podíval na to, zda opravdu každý klient musí mít svoje vlákno, zda nebude rychlejší jim data odesílat asynchronně v nějakém menším počtu vláken.

[Sten]

Doporučuji zkombinovat následující primitivy:

• událost nebo signál pro probouzení klientských vláken
• kruhový buffer jako bezzámková zero-copy paměť pro předání dat mezi čtečkou a vlákny klientů