Martin Albisetti se na svém blogu zamýšlí nad důsledky růstu počtu uživatelů Linuxu zapříčiněné kupříkladu prodejem notebooků Dell s nainstalovaným Ubuntu. Dle jeho mínění se zdá být logickým řešením problému s přetížením mirrorů prosté sdílení balíčků přes P2P sítě. Patrně není jediný, kdo si to myslí, protože již existuje program DebTorrent, který právě toto umožňuje.
Budeme balíčky stahovat přes P2P?
29. 5. 2007
28
nových názorů
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)Nehlede na to, ze v ramci bittorrentu se pouzivaji hashe jednotlivych casti, ktere by samy mozne podstrceni falesnych kousku baliku od ostatnich uzivatelu znacne zkomplikovaly.
-
McBig (neregistrovaný)Ja teda nevim, ale vzhledem k tomu co torrent dokaze udelat s provozem na siti, se absolutne dedivim, ze vetsina lokalnich ISP proti nemu broji. Hruza me jima, pokud se takhle budou sirit balicky. Mozna az vetsina klientu zacne byt rozumne nastavovana -> tedy musi to bud udelat programatori nebo uzivatele (takze zase nikdo), tak bude situace lepsi.
-
McBig (neregistrovaný)No jo, ale zapnete si nejakyho klienta na desktopu, nic moc extra nenastavujte, a pak se podivejte na pocet navazanejch spojeni atd.... proto mluvim o lokalnich ISP, ktery maji nejky ty wifi routriky. Levne zbozi - ono se jim tam vic ani nevyplati. Sluzby jako je torrent nebo DC++ umi s temahle levnyma routrikama udelat pekny divy :(
Ano, lze to nastavit atd, atd.. jenze kolik BFUcek to dela ? Az se tohle zmeni a zmeni se i zarizeni u tech lokalnich ISP, bude to pak ok. -
anonymníMyslim, ze Ivan Bibr s Vami souhlasi. Ja taky myslim ze distribuovat balicky pres Bittorrent
neni potreba, zatim jsem nezazil ze by nesly stahnout balicky Debianu z nejakyho mirroru. Kdyz neco nejelo, tak to bylo kvuli napadeni, nebo, pokud to bylo kvuli zatezi, to byly generovany html stranky o baliccich, kde to ten generator jaksi nezvladal.
Mnohem vetsi problem je pocet tech balicku, resp. jejich celkova velikost, coz se snad resi tak, ze nektere mirrory maji jen nektere architektury (i386 apod.). -
Miroslav SuchýStříbrný podporovatelTo že není problém teď neznamená, že nebude za pár let (a on bude). Je potřeba se koukat do budoucnosti a připravovat se na ni již teď. -
Ondrej 'SanTiago' Zajicek (neregistrovaný)Nevim, zda se jako zastupce sdruzeni CRFreeNet mohu povazovat za lokalniho ISP, nicmene proti torrentu nic nemam. Ani nevim, jake potize by mel zpusobovat. Vzhledem k tomu, ze pouziva TCP, tak by nemel byt problem ani se spatnou congestion control (a nebo pokud by byl, tak by mel byt resen na urovni OS).
-
Problém je s počtem spojení
Máte-li síť s 900 PC a hraniční router s NAT, tak vám s BT začne rapidně růst Connection tracking table.
Pokud si blbě nastavíte timeout a velikost týhle tabulky tak ji brzo zahltíte a nastanou potíže (odmítnutá spojení ...)
Někteří specialisti nám klidně vygenerovali desítky tisíc pokusů spojení za hodinu ... -
McBig (neregistrovaný)To mate pravdu, ale uprime receno me nepripada 2x v poradku, kdyz "desktopovy program" vytvori nekdy i vic pripojeni, nez se vyskytuje na hostingovem serveru. Zvlaste pak, kdyz na rozdil od toho hostingoveho serveru tyto spojeni v podstate ani nic nedelaji.
Pak krapet ne jen odpada deleni stanic na klient-server (coz je princip P2P), ale razantne se zvysuji naroky na sitove prvky, ktere pripojuji k internetu "jen obycejny desktop". A tento problem opravdu nemusi byt jen v NATu, ale jak sem uz zminoval, nektere routriky s tim proste maji problem - no ja se jim nedivim, kdyz 2MB routrik, pres ktery jede max 1Mbit najednou dostane nares 20K sponeji od 5 uzivatelu. -
Ondrej 'SanTiago' Zajicek (neregistrovaný)> ale razantne se zvysuji naroky na sitove prvky
Tohle je IMHO jen rozsirena povera. Pokud v sobe sitovy prvek nema NAT nebo jiny connection tracking mechanismus (coz obvykle sitove prvky nemaji), tak mu je celkem jedno, zda prepravi 50 000 paketu v ramci jednoho spojeni, nebo v ramci 10 000 spojeni. Napada me pouze potencialni problem s per-connection congestion avoidance, ten by se (pokud existuje) ale asi mel resit v ramci klientskeho operacniho systemu. -
McBig (neregistrovaný)Tak o ty povere to necham vysvetlit primo tomu zarizeni :D Uz nastesti u ISP nedelam, tak mam daleko klidnejsi spani, ale ano, videl sem nejaky AP, ktery pri vetsim poctu konexi vytvarel docela peknou latenci, i pres to ze v rychlosti problem nebyl. Coz je treba pro me osobne velkej problem (otevreny SSH terminaly atd).
Taky sem videl zarizeni, ktere v urcite souhre nastaveni uplne ignorovalo, ze ukoncene spojeni ma vymazat ze sve tabulky. Ano zarizeni umi veci :) Blba teplota, trocha udp paketu navic, chyba ve firmwaru atd.
A o tom co to asi tak dela se shaperem muzeme jen diskutovat. Jako kdyz pak router musi byt vykonejsi nez server - to je situace ponekud trapna. Fakt je ze proste male zarizeni na obsluhu 10ti pocitacu proste nemusi byt stavene na zatez 1000 pocitacu - coz plne chapu. -
Tak u P2P pro stahovani balicku je docela rozumny predpoklad, ze ven pujde jen relativne 'malo' spojeni, zbytek klientu by se automaticky mel pripojit k ostatnim pocitacum v siti, kde uz jsou balicky stazene (jedna-li se napr. o firmu s 900 PC, na kterych se provede hromadny update - jeho organizace je ukolem IT centra one firmy).
Jde-li o ISP, musi resit problemy s NATem (presne jak napsal Ondrej - je to problem NATu). ISP snad nema jako gateway nebo uzly s vyssim trafficem 'levne routriky s wifinkou'. Jestli ma, tak se temer urcite objevuji casto i 'bezne' provozni vypadky a mel by sjednat napravu.
A jestli se nepletu, tak pro P2P existuji i hranicni servery, ktere se o nej postaraji a snizi zbytecny traffic smerem do internetu. -
Ondrej 'SanTiago' Zajicek (neregistrovaný)
Tak u P2P pro stahovani balicku je docela rozumny predpoklad, ze pujde jen relativne 'malo' spojeni, zbytek klientu by se automaticky mel pripojit k ostatnim pocitacum v siti, kde uz jsou balicky stazene (jedna-li se napr. o firmu s 900 PC, na kterych se provede hromadny update - jeho organizace je ukolem IT centra one firmy).
A tohle v ramci bittorrentu nejak funguje? AFAIK ne, nebo alespon ne bez nejakeho dalsiho software na gateway dane organizace. Vite o necem takovem? -
Palo (neregistrovaný)Neviem o nejakom mirrore ktory by bol obzvlast pomaly. Obvykle su to mirrory sf.net ktore maju problemy. A ak budu nech si to Dell s Ubuntu riesi. Ja si na SK mirror debianu stazovat nemozem. Na rychlej linke server do 10 min. nainstalovany. Iba security update myslim chodia z centraly a to je obcas pomale.
-
hlavac (neregistrovaný)Nejlepší by bylo kdyby si počítače na LAN mohly ty updaty předávat navzájem.
Třeba kdyby se instalací neztratily informace nutné k znovusestavení balíčků s updaty v originální distribuční formě (aby se nemusely skladovat celé balíky).
Pak by se nově nainstalovaný komp mohl poptat po updatech kolem, a teprve co tam nebude by sháněl jinde (upstream). Možná by se dal udělat i nějaký distribuovaný mirror i těch nenainstalovaných updatů.
Při použití digitálních podpisů by takhle mohly spolupracovat jinak zcela nesouvisející počítače, pěkně hierarchicky podle konektivity (LAN, ISP, peering v rámci země, síťově okolní státy, master mirror).
Možná konečně nějaká motivace pro přechod na IPv6 - skupinové adresy a anycast? ;) -
"update" deb baliku je nova verze celeho baliku.
Vetsina nedavno instalovanych baliku na danem kompu je ulozena v cache.
Takze kdyby se vyresilo automatizovane lokalizovani a pripojeni k takovemu pocitaci, tak pak uz nic nebrani si ty nove verze balicku z neho stahnout a updatnout s nimi jiny stroj.
A jinak si taky myslim, ze veskere balicky v repozitari by tam meli byt 2x, jednou jako kompletni balicek, a jednou jako nejaky diff k predesle verzi. Ten kto by pravidelne updatoval by tahal jen diffy, zbytek kompletni balik.
Autor zprávičky
