Já osobně bych se radši přiklonil k vytvoření speciálního bittorent trackera. Idea je, že klientů je plno a jsou kvalitní. Pokud si myslíte, že vytvoříme společně dostatečně kvalitní klienty, použitelné ve windows i linuxu, které uživatelé budou chtít používat, já si to nemyslím.
Naproti tomu, pokud by bylo možné efektivněji využít již existující programy, s tím že se jenom vylepší existující servery, má to větší šance na úspěch i popularitu.
Co je podle mě problém zásadní v czfree síti je neexistence centrálního bodu, jak se tu navrhuje. Všechny centrální body potřebují dobrou konektivitu od všech klientů, což je problém celé czfree sítě. Sice se situace podle všeho výrazně zlepšila, ale pořád tady tento problém je. Aplikace musí existovat bez centrálního bodu. Pokud jsou huby schopné dostatečně jednoduše se seskupovat, je možné toho využít. Osobně jsem ale pro otevřené protokoly, a myslím že bittorrent tohle taky může zvládnout.
Můj hlavní požadavek vidím jako naprostá absence centrálního bodu. Musí to být něco typu czf4bfu, kde se servery nemusí dostat ke všem ostatním.
Požadavky na decentralizovaný tracker:
tracker má svoje klienty, kterým dává adresy klientů.
tracker je schopen se kontaktovat s dalším trackerem, a vyměnit si s ním svoje klienty, tedy získat mimo svých zájemců i cizí, a nabídnout cizím obsah svých klientů
tracker umožňuje probublávání takovýchto klientů dál a dál sítí. Takové adresy klientů by ale měly mít nějakou metriku, dá se předpokládat, že klienti ze vzdálených hubů nejsou na tak dobré lince, jako jsou klienti bližších trackerů.
Otázka je, zda je schopen tracker nějak upřednos?novat místní klienty, nebo volba závisí pouze a jenom na klientovi samotném. Nemám zas tak detailní přehled o protokolu bittorrentu, takže jenom doufám, že tohle možné je.
Taky je otázka, jestli těch adres nebude přiliš, pokud se spojí větší počet trackerů. Myslím ale, že tohle nebude častý stav, budem rádi když bude někdo sdílet.
Myslím si taky, že kromě větší penetrace trackerů a stahování primárně od bližších peerů by mělo mít sdílení na starost spíš shapování. Kvalita linky může být hoodně proměnlivá, a myslím že by bylo asi těžké určit, kde je linka kvalitní. Rozhodně počtem skoků se to určit nedá. Rozumnější metoda je z costů rout z quaggy, která už může vypovídat o něčem jiném, pokud optika má jiný cost než wifi. Stačilo by asi přeparsovat výstup ospf route a podle metriky určit. Opět nemusí vždy platit, myslím že třeba routy z BGP mívá metriku jinak, podle stroje, který je do ospf distribuuje. Taky tahle metoda nedosáhne za hranice cloudu. Otázka je, co udělám s informací, který klient je ten lepší. Možná se dostanu k tomu, že fakt musím napsat svého klienta.
Jinak výše mnou popsaný decentralizovaný tracker by fungoval pro diskutované použití asi jenom v případě, že by existovaly lokální torrent downloadery a seedery, které by potom těm blízkým klientům poskytovali již stažená data.
Zásadní je to, aby celá sí? použila stejný torrent, a měli jej dostupný mezi sebou, tedy aby nebylo 5 oddělených trackerů, ale 5 nezávislých ale spolupracujících trackerů. Tedy pokud by to někdo neměl blízko, stáhne se to pomaleji s větší dálky.
Nebijte mě prosím, jestli můj výmysl bittorrent není schopen realizovat. Neznám protokol do detailu.
Myslim, ze muj puvodni napad ponekud zmutoval :-) Nabizi se tu reseni, ktere stavi na sexy "P2P" sitich/protokolech, nicmene tyto protokoly nejsou pro infrastrukturu CZF vhodne. Predpokladaji totiz, ze v siti je spousta volneho pasma (coz v CZF neni).
Podle me by bylo celkem jednoduche vytvorit system distribucnich NODU, ktere by byly schopne pracovat s nejakym distribuovanym filesystemem. Tuhle infrastrukturu je pak mozne se znalosti topologie slusne spravovat.
Jake DFS jsou k dispozici na platformach provozovanych v CZF, moc netusim.
__________________
Nemam rad Jestirky (vcetne popiracu Holocaustu a 9/11).
Ovšem to funguje tak, že obsahuje reference na konkrétní svazky sdílené sambou. Replikaci to nijak neprovádí, takže by musel nastoupit nějaký rsync nebo takového něco, sesynchronizovat to, a potom dát link do hlavního stromu. Nicméně fungovat by to mohlo, když někdo napíše ty synchronizační skripty.
no a co takhle (bittorrent only):
na vhodných místech (třeba 1x v každém cloudu) bude běžet bittorrent klient.
V období nízkého trafficu (třeba ve 2 v noci) se zaktivuje skriptík, který ze známých trackerů stáhne čerstvý torrenty a předhodí je klientovi.
Po zaplnění disku se automaticky smažou nejstarší kusy.
Výsledek bude, že v období špičky budou sosači zatěžovat spíš lokální sí? , anžto jim to pojede rychlejc.
Nevýhodou nutnost evangelizace uživatelů k většímu využívání torrentu na úkor DC.
v tom prave vidim problem. torrent tu byl, a umrel na nezajem. o DC zajem je. ja sam torrent taky uzivam, a u nas v siti jej pouzivaj se mnou dalsi tri lidi. z celeho naseho cloudu se neprepocitam, kdyz udam cislo 5.
osveta je mila vec, ale nikdo na ni nereaguje. Navic nemam k dispozici dostatecne velke SCSI disky do serveru, Cluster by to jinak utahl. problemem je take vytizeni, kdyz predelavas torrenty. ale to se da samozrejme obejit jinak/neni nutne.
__________________
V.I.R.N.I.K: Vigiliant Individual Responsible for Nocturnal Infiltration and Killing
Resistance is, and always has been futile...
25.09.2006 v 21:44
