P2P traffic tvorí majoritu všetkých prenášaných dát na svete, okolo 70~80 perc. a tento podiel stále rastie. Poskytovatelia služieb sa to snažia riešit rôznymi FUP alebo shape-ovaním rýchlostí pre P2P protokoly. V takejto situácii, kde ISP stojí nemalé peniaze iba P2P traffic a zároveň nedokážu poskytovať plnohodnotné - neobmedzované služby svojim zákaznikom, je na mieste pozrieť sa na problém z iného pohľadu, nie reštrikcie vyriešia túto situáciu, ale prispôsobenie sa tomuto rastúcemu trendu. Nasledujúci koncept sa nie len prisposobuje, ale aj plne v prospech všetkých zúčastnených využiva možnosti siete a P2P technológii tak, aby masívne znížil podiel P2P dát na backbone spojoch a zároveň ISP bol schopný poskytovať NEobmedzované služby svojim zákazníkom, celý systém funguje absolútne transparentne voči všetkým existujúcim P2P systémom.
Celá myšlienka by sa dala zhrnút do jednej vety ako decentralizovaná hierarchicky-stromovo radená štruktúra fast-cache serverov využívajúcich Similarity-Enhanced Transfer (SET) a rozpoznávanie dátovych tokov. P2P systémy rozdelujú dáta do menších blokov vo veľkosti od 32kb az do 1MB, každý tento blok má svoj vlastný hash. V kontrolných dátach - napr. pri protokole bittorrent /budeme pre vysvetlenie používat práve tento protokol, pretože je najpoužívanejší, samozrejme podobne to funguje aj pri iných sieťach/ to je súbor s koncovkou .torrent, sú tieto hashe vždy priradené k svojmu miestu, následne klientská aplikácia číta kontrolné dáta a pripája sa na tracker, kde si vyžiada blok s daným hashom, naspäť je jej ponúknutý host / hosty ktorý tento blok vlastní, klient sa pripojí a ťahá. Similarity-Enhanced Transfer funguje tak, že tieto bloky môžu byť pre rôzne dáta rovnaké, alebo podobné a teda sa značne rozširuje množstvo hostov, od ktorých sa dá ťahať. SET sa však prakticky nedá využiť v reálnom živote, pretože by x-násobne zvýšil náročnosť na všetkých stranách, ale hlavne vyhľadávanie by sa stalo neúnosným. Väčšina operátorov sleduje a hodnotí dáta, ktoré užívatelia prenášajú, preto nie je problém filtrovať dáta istých protokolov, prípadne ich dátovy tok preposielať cez nejaký iný uzol. Ten uzol následne môže čítať dáta a pokiaľ ide o požiadavky o istý blok dát identifikovaný hashom vyhľadať, či daný blok nemá lokálne uložený, ak áno, odpovie klientovi tváriac sa ako tracker, príp. pri iných sieťach klient, ktorý má ten blok, pripadne sa dá postupovať, aby sa nezachytávali požiadavky na tracker, ale až pripájanie a komunikácia priamo s držiteľom dát, niečo ako Man-in-the middle attack, ale s tým, že by sme poskytli bloky priamo my, klient by si myslel, že mu dáta chodia od správneho odosielateľa /nie je problém meniť IPčky v packetoch/. Pokiaľ by sme daný blok dát nemali, jednoducho by sa požiadavka pustila ďalej bez akéhokoľvek zásahu. Tu prichádza na rad hierarchickost - pokiaľ by sa požiadavka zachytila na nejakom ďalšom stroji počas svojej cesty a ten daný stroj by mal daný blok, proces by sa opakoval. Odpoveď od tohoto stroja by bola ale zachytená na tom pôvodnom cache serveri a zaradil by daný blok do cache, týmpádom pri opakovanom prístupe k danému bloku by požiadavka nemusela byť forwardovaná ďalej. Jednotlivé cache servery nemusia o sebe vôbec vedieť. Položky z cache by sa po určitom čase bez prístupu k nim zmazali.
Prezentované riešenie by dokázalo odbremeniť siete od náporového sťahovania rovnakého contentu a čiastočne odbremeniť pri ostatných dátach. Ideálna situácia by bola, keby sme dokázali celý P2P traffic udržat iba na last-mile spojoch, jednotlivých PPP linkách koncových používaťeľov. Dátovy tok by zaťažoval iba ich linku, za ktorú si platia. Radšej ťahať niekoľko sto MB/s z lokálneho serveru pre lokálny segment, ako tých niekoľko sto MB/s posielať ďalej. Samozrejme, že jeden takýto cache server nespasí svet ...
Požadovaný HW - akýkoľvek server, a zopár TB diskové pole. Pri súčasných cenách to v porovnaní s ponukanými výhodami je zanedbateľné. Vzhľadom na to, že P2P dáta nie sú time critical, zvýšený processingový čas a teda oneskorenia požiadaviek/odpovedí, nie sú podstatné.
A teraz Vy, chcem počuť názor každého ...
PS: V súčasnej dobe existuje niečo, čomu sa hovorí bittorrent cache server, ale to je vlastne iba server, ktorý má dáta a ustavične ich seeduje ... Čo sa týka iných sietí, tak niečo sa robilo okolo cache serverov a tuším siete Kazaa ale velmi o tom nepočuť. Ja sa jednoznačne prikláňam a favorizujem protokol bittorrent, nakoľko je univerzálne použiteľný /update aplikácii, nárazové sťahovanie, legal aj ilegal content ... /
[edit by vektor: odstranil som chybne newline]
diky vektor
______________________________
my life is better than sci-fi
Nebol by v tom problém, čo sa týka zákonnosti?
myslim ze nie, pretoze je router zodpovedny za to ze smeruje tok dat ktore obsahuju napr. ilegalne filmy ?
a takisto by boli chapane aj tieto cache servery, oni pozeraju po najmensich blokoch dat z ktorych nie je zrejme z coho povodne pochadzaju, to je ich vyhoda, to je SET - tieto bloky vedia byt pouzite aj inde ako pri povodnych datach ...
ale good point
______________________________
my life is better than sci-fi
Jediny problem je sifrovany prenos, pripadne tahanie sifrovanych suborov. V pripade sifrovaneho prenosu su prostrednici celkom vyradeni. V pripade sifrovanych suborov je sice mozne cachovat bloky jedneho a toho isteho suboru pre viacerych userov, ale pravdepodobnost ze 2 rozne subory budu mat jeden rovnaky blok je miziva (mozno az na par bajtov hlaviciek).
Kompresia tiez znizi mnozstvo moznych rovnakych blokov. Jedina vynimka su rozne archivy v ktorych je zapakovane to iste sice rovnakym algoritmom (napriklad rovnakou verziou a nastaveniam RARu), ale trochu pomenene a poposuvane. Otazkou je video a zvuk.
--------------------------------------------------------------------------
Lidi delaj bejkarny, takhle to proste je a bude. Mjr. Dastych
zase raz dobra pripomienka, dakujem
pokial viem P2P data nebyvaju kryptovane, uspesnost SET zalezi od velkost blokov dat, cim mensie su tie bloky tym je vecsia sanca ze sa budu opakovat ... samozrejme cim su mensie bloky tym ich je viac, takze v praxy sa dava velkost blokov co najvecia aby sa setrili trackery ... pokial by sme ale takto fungovali, verim tomu ze by ludia zacali davat coraz mensie bloky
mas pravdu sifrovany prenos je problem, a bojim sa problemu menom IPv6 ... pretoze tam je vsetko end-to-end sifrovane a teda man-in-the middle ako chceme robit by bol kusok ze problem .... nastastie IPv6 realne nehrozi ... fuuuha :)
______________________________
my life is better than sci-fi
No ako som ti pisal na ICQ, pockam si na vyjadrenie ISP (znamy) ale
1.) sifrovany prenos, vies s istymi obtiazami doriesit
2.) IPv6 ... no to by bol problem.
otazka znie ako by sa to spravalo pri torrente ked mas iste moznosti ako obist politiky.
Napriklad uTorrent ktoremu das port 8080 ako zabezpecis filter aj na 80?
----------------------------------------
Hlúposť užívateľa je úmerná jeho právam.
rozpoznavanie torrent trafficu nemusis vobec riesit to zriesi ciskac a priamo iba to bude forwardovat na cache server :D
______________________________
my life is better than sci-fi
co sa tyka charakteristik a uspesnosti SET ... da sa to vygooglit, pohybuje sa to v desiatkach percent ...
to je o tom, ze hash je generovany podla obsahu, a teda vieme zistit ze ked je v hashy nejaka odchylka mala tak aj ten blok bude podobny ... viac info na wiki
vseobecne to SET je len taka pikoska a berieme z nej vlastne len posielanie opakujucich sa blokov, pretoze neverim velmi na to aby som kontroloval podobnost k hashom, to by dost zatazovalo a zaroven pri niektorych typoch dat je to nezelane ... pri filmoch a hudbe sa minimalne rozdiely malych blokov stratia, inde vsak nie ...
______________________________
my life is better than sci-fi
myslim ze tento problem netreba vlastne ani riesit, pokial bude povoleny P2P traffic ktory bude vyhovovat istym urcenym pravidlam, napr. ze nesmie byt kryptovany a ostatny bude napr. shapovany alebo rieseny FUP tak potom ludia budu musiet pouzivat to na co sa toto riesenie vztahuje ... bohuzial, technicke moznosti to limituju ... ale fakt dakujem za nazor, vobec ma nenapadlo zvazovat kryptovane data
______________________________
my life is better than sci-fi
Myšlienka to pekná... Ale:
Jednoduchší prístup je poskytnúť ľudom možnosť stiahnuť si všetko "z lokálky", teda napríklad vlastný p2p hub u providera. Ako to má napríklad jeden bratislavský "undergroundový" provider. P2P traffic mimo sieť providera hodiť cez shaper alebo zakázať v business hours úplne, v rámci siete pustiť točku naplno. Zaťažíš síce backbone, ale výrazne odľahčíš drahé prestupy.
diky za pripomienky, podme na to:
- v dnesnej dobe nie je so sucasnym HW problem sledovat datovy tok na urcite data a filtrovat pripadne processingovat podla nejakych kriterii, co sa tyka samotneho toho nasho processingu tak jeho narocnost sa da vyratat pretoze by ten cache server musel spracovat kazdy jeden p2p packet ktory zachyti, overit voci DB a vykonat akciu, pocitam s datovym tokom niekolko desiatok az stovak MB/s na jeden server ... ano, chcel by som ist po jednotlivych packetoch, pretoze ake packety my potrebujeme pozerat ?
nie datove, iba hlavicky a aj to iba pri inicializaciach spojeni ... kde zistime ci tie dane bloky mame alebo nie ... datove iba ked tie bloky nemame a aj to iba z toho streamu, takze to nie je az take strasne
- hashe a ich kolizie, to je na inu debatu, kolizie su dost ojedinely a aj v umelych podmienkach tazko generovatelny ukaz, a aj to nie u vsetkych hashovacich algoritmoch .... takze sa toho netreba realne bat, co sa tyka zistovania prislusnosti k streamu tak to sa da riesit dost jednoducho viacerymi sposobmi, taky conntrack alebo vlastna low-level funkcia ... pri TCP je to banalne a ostatne sa daju zriesit tiez
- mnozstvo cache server - ideal si predstavujem na poslednych ISP routroch v ceste, zoberme si take mensie mesto ako poprad, niekolko tisic DSL pouzivatelov ... centrala ST v poprade /berme ST ako priklad, su vsade/, posledne ISP routre ... a tam na tychto niekolko tisic pouzivatelov jeden stroj ... samozrejme to sa znovu da vyratat kolko a akych strojov potrebujes, vieme statistiky ake p2p datove toky kolko dat bolo v minulosti, podla toho a efektivnosti riesenia sa da presne urcit potrebny HW, na toto vsak potrebujeme urobit nejaky testing aby sa to dalo odhadnut ...
- ako som povedal ja si to predstavujem tak aby napr. mal ST v kazdom meste nieco take, samozrejme KE a BA podla potreby viac, a nasledne dalsie na medzinarodnych pripojoch, tazke mas pokrytu aj backbone aj prestupy, to som myslel tou hierarchickostou, najprv sa skusi lokalny server, nasledne ked nema tak ten dalsi v poradi k originalnemu cielu, takze niekde v BA alebo az na prestupe, este pred nim, ked ani tam nic, tak az tak to ide dalej .... centralizovane riesenie nie je dobre, musia slapat samostatne, oddelene, transparentne
- co sa tyka jednoduchsieho pristupu, to nie je celkom vyhodne, pretoze je to ilegalne a zabudas na SET, toto riesenie je viac low-level a nepozera na data ale iba na bloky a teda jeho legalnost je nenapadnutelna a zaroven je aj efektivnejsi a globalnejsie pokryva potreby pouzivatelov pretoze mas bloky a nie iba nejake iste data, tie bloky maju vyssiu univerzalnost ...
som rad ze si sa do toho tak oprel, diskusia je velmi produktivna forma spoluprace :)
______________________________
my life is better than sci-fi
Či je to so súčasným hw problém alebo nie... záleží od trafficu. Provideri začínajú mať problém vôbec stíhať dáta "pchať do rúry", a to ešte nemáme všade fttp (k čomu to ale pomaly speje) - nie to ešte nejako tie dáta spracovávať (a nebodaj ešte logovať, ako by si to polícia&spol. možno chceli predstavovať).
Ono by to asi chcelo vykalkulovať, že čo by taký cluster v každom väčšom meste stál (vrátane maintenance), a koľko to ušetrí z trafficu na linkách (vyjadrené v peniazoch potrebných na upgrade z dôvodu nepostačujúcej kapacity, alebo v cene za prenesené dáta).
Kolízie hashov... md5 je afaik úplne rozbité, a sha1 je na rade (zatiaľ 2^63). Použitím zložitejšej hash funkcie ďalej zvyšuješ výpočtové nároky na caching server.
Navyše, ako zákazník chcem prenášať vlastné dáta a nie to, čo si nejaká cache myslí, že chcem.
Ako je to s legislatívou lokálneho hubu, neviem. Možno sa to dá nejako zastrieť (akože-pravidlá). Na to by to chcelo nejakého naozajprávnika, nie iba dohady IT odborníkov.
Som rád, že oceňuješ moju, dúfam že konštruktívnu, kritiku ;).
- co sa styha a ako to sa uvidi ked to otestujem .... ono je to extremne primitivny algoritmus takze by naozaj nemal byt problem, moje skusenosti so spracovavanim dat su zatial take ze ma vysledky vzdy prijemne prekvapili :)
- hashe - uz som sa vyjadril
- vola zakaznika, neviem teraz na co narazas, asi sa nechapeme, ty vobec ako zakaznik nie si odkazany na to co je v cache nijako ta neobmedzuje
______________________________
my life is better than sci-fi
Len mala poznamka k tym koliziam v hashoch. Tie samozrejme existuju vzdy ked sa mapuje nieco variabilnej velkej dlzky do pevnej mensej. V kazdej hash funkciii je ich mnoho. Pointou hashovacej funkcie je ze sa nedaju najst tak lahko.
To ze by nastali spontanne je ale velmi mala. Tie kolizie co sa najdu su specialne konstruovane.
Samozrejme podla hashov sa ani nesmie dat zistit ze dva hashovane texty su si podobne, to by bol trapas. Tu ide o trochu nieco ine, zrejme o hashovanie nejakych mrnavych "podblokov" daneho bloku kde je pravdepodobnost zhody dost velka a urcenie podobnosti blokov podla poctu zhod tychto mensich "podblokov"..
--------------------------------------------------------------------------
Lidi delaj bejkarny, takhle to proste je a bude. Mjr. Dastych
tak nejako, diki akira ... ja podobnost ani nechcem riesit, boli by s tym iba problemy ...
ako som povedal chcem SET vyuzit s pohladu opakujucich sa blokov nie z pohladu podobnosti ...
podobnost mozno raz ked to bude premakane, isto fungujuce ... ale kto vie :)
______________________________
my life is better than sci-fi
a este dalsia vec, vobec nepotrebujem a ani nechcem pozerat na vysie datove entity ako su bloky, vobec nepotrebujem a nechcem a nemam preco zistovat prislusnost blokov k datam ... keby som to robil, uz by to bolo pravne napadnutelne za istych podmienok ... a taktiez nevidim dovod preco by som to mal zistovat
______________________________
my life is better than sci-fi
A este jedna vrtacka otazka v suvislosti s p2p ma napadka. Ono totiz nie je problem ze uzivatelia nieco stahuju. To by este islo, ale musia aj sami seedovat. Moze sa stat ze na 1 connection download ficia tri uploady opacnym smerom. s nimi by si SET asi neporadil (pri useroch zvonku, linka do SIXu alebo medzinarodna by bola vytazena rovnako iba ze by ich ISP tiez pouzival SET).
--------------------------------------------------------------------------
Lidi delaj bejkarny, takhle to proste je a bude. Mjr. Dastych
no ano, to som spominal uz v clanku ... jeden takyto cache server svet nespasi ...
______________________________
my life is better than sci-fi
ok, uz sa pomaly ale isto crta nejaky prototyp ... vela veci riesim kusok odlisne ako som spomenul v clanku, jednoznacne vsak vypustim nejaky material ked to bude hotove ...
cest praci :D
______________________________
my life is better than sci-fi
ok, vyzera to tak ze mam vsetky casti riesenia uz ako tak hotove ... uz ich iba spojit a odladit moju modifikaciu ctorrentu
aj ked to este nie je hotove ale chcel by som sa uz podakovat marjanovy a specialne ixxovy za pomoc ;)
______________________________
my life is better than sci-fi