Tohle je prave otazka. Protoze centralni indexy vetsinou obsahuji jen .torrent soubory, ale uz ne primo warez, takze si nemyslim, zeby je nekdo moh zavrit.
> neexistence optimalizovaneho klienta napsaneho v jazyku nizke urovne (stavajici implementace v pythonu a jave jsou pomerne narocne na vypocetni vykon - nelze napr. stahovat z 20 torrentu soucasne, i kdyby to rychlost linky umoznovala)
Ja pouzivam mldonkey (je to Ocalmu, takovej starsi francouzskej programovaci jazyk) a i kdyz tam je podpora BT jen v alpha verzi a je obcas buggy (treba nekdy blbne kdyz ma rozpakovat vice souboru), tak s tahanim 100 torrentu najednou nemam problem. Zere to ovsem silene pameti, kdyz sem to pustil se specialnim kernelem bez limitu procesu a FD, tak to nekdy oteviralo az 5000 FD za minutu a 1.5GB pameti pouzivalo z 95%. Za jediny den sem mel spojeni s 3 miliony unikatnich IP address. Chudaci co mne sledovali, ten log musel stat za to:-)
> kratkodobost distribuce (pote co lide soubory stahnou, od torrentu se odpoji a ten postupne vymre)
Tohle je asi nejvetsi problem BT.
Treba ve stredu vecer maji premieru ve Statech tri serialy co mne zajimaji (SG,ST a Angel), takze ve ctvrtek rano uz je nekdo releaznul (grab + vyeditovani reklamnich bloku + kodovani do divx/xvid/mpg), behem ctvrtka to sdili 600-1000 lidi a tece to klidne i 600kB/sec, ovsem o tyden pozdeji to sdili (seeds) uz jen 20-50 lidi a o mesic pozdeji 1-5.
V podstate to cloveka nuti, aby to tahal s tou prvni vlnou stahovacu a to je prave ten problem BT - vyhodny je jen kdyz to taha hodne lidi najednou.
Na rozdil od klasickych P2P siti kde to sice funguje podobne (taky tam jsou vlny), ale sance sehnat neco starsiho a vzacnejsiho na rozumne rychlosti (ovsem radove nizsi nez v BT) je mnohem vetsi.
Jinak souhlasim s tim, ze pouzivani BT na sireni legalni distribuce je fakt skvela myslenka. Pro sdileni nelegalnich programu to zas takova vyhra neni (viz muj prispevek nize), ale koneckoncu to autor puvodne ani nezamyslel, neni to proste nahrada P2P.
Zdravím, pokud jde o toho lepšího klienta, používám na FreeBSD ctorrent (klient napsaný v jazyce C). Spolehlivý malý prográmek s nízkými nároky na systémové zdroje.
Více viz http://ctorrent.sourceforge.net.
bittorrent je masivne vyuzivan uz aspon rok a pul, tudiz hovorit o nem jako o novem obevu mi pripada ponekud zvlastni. Je pravda, ze warez na nej prisel pozdeji, ale distribuce redhatu ci masivni rozsireni fansubu tu jsou jiz dele. Jedinym duvodem, proc se podle meho nazoru BT v cerne zone uchytil je, ze ackoliv je pro majitele prav relativne snadne vyhledat a zavrit tracker, nez dobehne urednicky proces tento uz nebezi.
Ackoliv se ale clanek snazi (pokud jsem to tedy pochopil) vyzdvihnout klady a zapory BT, prave to je vec ktera v clanku chybi. Nehlede na nepresnosti stylu "Vyloučení sítě z provozu (......) prakticky nepřipadá v úvahu." nebo nemoznost distribuce kratsich souboru (jeden torrent muze obsahovat adresar souboru)
takze abych to shrnul:
klady:
* vysoka rychlost (vsichni se vrhnou na jednu novou vec najednou; system nuti uzivatele vracet formou uploadu, jinak nejede download)
* velmi mala rezie dat (typicky na freenetu postavena winny ma rezii v radu 30% a vyse, u BT je odhadem nekde pod 5% velikosti souboru)
* snadne udelat vlastni tracker (BT server); a na rozdil od P2P siti clovek vi, co pres tento system tece - lide jsou ochotni obetovat nejaky procesorovy vykon a sitovou kapacitu pro neco o cem vedi ze ma smysl, mene uz do cerne diry p2p
* snadna integrace do webu, komfortni ovladani (krome warez ap stranek, ktere BT vyuzivaji jako dalsi zpusob jak zobrazit popup okna co nainstaluji dialery, tu mame napr. i pomerne povedene www.animesuki.com, ktere zastupuje sedou zonu - sice nelegalni, ale trpene az podporovane spolecnostmi jejichz prava porusuje)
* totalni kontrola obsahu majitelem trackeru
zapory:
* totalni kontrola obsahu majitelem trackeru
* kratkodobost distribuce (pote co lide soubory stahnou, od torrentu se odpoji a ten postupne vymre)
* snadnost cenzury a zastaveni distribuce nezadanych materialu odpojenim centralniho indexu (kompenzovana kratkodobosti...)
* neexistence optimalizovaneho klienta napsaneho v jazyku nizke urovne (stavajici implementace v pythonu a jave jsou pomerne narocne na vypocetni vykon - nelze napr. stahovat z 20 torrentu soucasne, i kdyby to rychlost linky umoznovala)
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).