BitTorrent

Från FZ Wiki, Sveriges största gamingwiki.

BitTorrent (eller BT) är ett protokoll för filöverföring utvecklat av Bram Cohen som finns implementerat i ett klient/server-program med samma namn. Genom att använda denna mjukvara är det möjligt att distribuera filer över ej stabila nätverk.

Överföringarna koordineras av speciella textfiler, kallade torrent-filer (med fil-ändelsen .torrent), vilka hjälper BitTorrent-klienten samordna överföringarna till andra användare. Dessa .torrent-filer innehåller information om filer som skall laddas ner och adressen till den sk trackern (se nedan) som tar hand om koordinationen av filnerladningen. Detta innebär att du med BT kan ladda upp/ned en fil och använda den sammanlagda bandbredden från alla klienter - vilket gör att den server som lägger upp filen inte behöver bidra med mycket mer än den mängden uppladdning som krävs för att ladda upp filen ett par gånger, användarna kommer efter hand tanka ner av varandra istället.

Den största nackdelen i BT-protokollet är kravet på centrala sk trackers som håller reda på alla personer som vill få hem den specifika filen, dessa trackers kan en centralplats med nog CPU-kraft och bandbredd beroende på storlek. När Red Hat 9.0 släpptes så stresstestades Bittorrent första gången, och där var den totala överföring bland alla klienter 2TB/s och trackern använde en 256Kb/s lina.

Djupgående information

Termer

Det finns för BT ett antal olika termer som ofta används:

• Seed = En person som har hela filen tankad och färdig och sitter bara och skickar iväg data
• Leecher = En person som inte har hela filen tankad men som sitter och tankar hem den.
• Original Seeder = Den som först skickar upp filen.

Hashning

BitTorrent använder sig flitigt av så kallad hashning för att kunna garantera integriteten av filer. Personen som först skapar .torrent-filen hashar filen genom ett externt program (se nedan) och skapar därför ett, kan vi säga, unikt fingeravtryck för filen. Dessutom hashas alla bitar av filen (storlek kan väljas själv, 256 Kb är vanligt), vilket gör att vi förutom att garantera filens integritet kan garantera integriteten för alla 256 KB stora bitar av den. Vi kan därför, efter att ha fått hem en bit, undersöka ifall den stämmer överens med just den hash vi vet den biten ska få, gör den inte det kastar vi bort den och försöker igen.

Överföring

Om klienten har satts igång med att försöka få hem de filer som specificers i en .torrent-fil så kommer klienten att först ansluta till den tracker som beskrivs i .torrent, och skapa de filer som specificeras i filen (dessa filer kan antingen ha storlek 0 för att sedan fyllas på allt eftersom, eller i andra implementationer få den exakta storlek de kommer få senare, fast då fylld med ointressant info som kommer bytas ut). Vi får sedan en lista på andra klienter som också försöker tanka hem filen och vad de har för bitar. Information utbyts sedan om vilka delar av filen vi vill ha (i tidigare implementationer är det helt slumpmässigt, medan det i vissa är så att den mest ospridda biten som efterfrågas först). Vi frågar alltså alla andra klienter om dessa bitar (begärande många olika bitar samtidigt för att få ut en bra effektivitet, sk pipelining).

För att kunna införa en viss ge-och-ta system så finns det i protokollet en sk choke-idé beskriven, dvs att en klient är för upptaget med andra saker och kan inte skicka. Detta kan då användas för att begränsa skickandet, då TCP har problem om mycket ska skickas i många olika anslutningar samtidigt, och för att vi (som vi nämnde) ska kunna implementera ett visst ge-och-ta beteende då vi vägrar skicka tills den andra klienten har skickat till oss. När vi sedan får hem en bit meddelar vi det till resten av folket så kan de uppdatera sin info.

Uppdelningen i bitar gör att vi kan ha en komplett version av filen utan att en enda klient har hela filen

Detta hanteringen av bitar av filen som beskrivs ovan är en viktig del varför systemet fungerar bra. Istället för att sekventiellt tanka hem en fil (som att tanka hem från tex en webserver, vi tankar från starten av filen till slutet) så tankar vi hem olika delar av filen. Detta gör att om filen bara består av 9 bitar så kanske person A har bit 1;4;5, person B har 2;3;6 och person C har 7;8;9. Ingen av personerna i sig har hela filen, men tillsammans kan de lyckas få fram hela filen. Detta betyder att när vi initiellt försöker föra ut filen (dvs vi är de första som har filen, vi har den ENDA kompletta kopian) så kan vi skicka iväg olika bitar till olika personer och de tvingas sedan arbeta tillsammans för att få ihop hela filen, vilket gör att de utnyttjar varandras hastighet istället för den ursprungligade uppladdaren.

Vad man vill göra är därför att minimera hur mycket data man tvingas skicka innan resten av klienterna själva kan hantera situationen och bygga ihop den kompletta filen. I tidigare implementationer skickade klienten egentligen upp data efter hur de andra klienterna efterfrågade den, vilket kunde resultera i att man kunde vara tvungen att skicka upp 150-200% av filens storlek innan den fanns spridd (skickade upp samma bit flera gånger). I nyare klienter (tex Shad0ws, Azereus) så finns det något som kallas Super-Seed mode som helt enkelt bygger på att vi gömmer bitarna från resten av klienten. Sen tar vi och avslöjar för dom att "aha vi hade bit X" som vi då vet att vi aldrig skickar förut, och sen nästa gång hittar vi en annan intressant bit som aldrig skickats förut osv. Detta betyder att vi minimerar dupliceringen av utskickad information och vi kan lyckas få ut hela filen efter 105-110% uppskickad data (inte helt perfekt system + att andra klienter kanske går offline med de unika bitarna de hade).

Fördelen med hasning och överföring i ett

Ett vanligt sätt att överföra stora filer är att använda sig av RAR som delar upp filen i massa små delar, så att man kan vara säker på att :

• filen är hel och oskadd
• man behöver inte ladda ner hela filen igen om någon del är skadad

Det är precis på samma sätt som Bittorrent fungerar. Hashningen ser till att filen är hel och oskadd, och du laddar bara hem den delen du behöver. Fördelen med BT är att du fortfarande har en oskadad fil som går att använda, även om du inte har hela filen nerladdad. Alltså en filmtrailer nerladdad med Bittorrent kan mycket väl vara möjlig att se om den är 90% färdig, medan om du tankar hem RAR arkiv så måste du ha hela filen.

Program

Klienter

• µTorrent (http://www.utorrent.com) - Rekommenderas starkt. Liten filstorlek, låg minnesanvändning, väldigt snabb, och full av funktioner!
• BitSpirit (http://www.bytelinker.com/intl/index.htm)
• ABC (http://pingpong-abc.sourceforge.net) - (Another BitTorrent Client)
• Azureus (http://sourceforge.net/projects/azureus/) - Java-baserad klient med avancerade funktioner.
• BitTorrent - officiella klienten (http://bitconjurer.org/BitTorrent/) - Skriven i Python, den som sätter de facto-standarden, kan ses som en bra riktlinje.
• BitComet (http://www.bitcomet.net) - Skriven i C++
• Burst! (http://krypt.dyndns.org:81/torrent/)
• Shad0ws Experimental BT client (http://ei.kefro.st/projects/btclient/) - Direkt utveckling av officiella klienten, numera nerlagt och ersatt av BitTornado.
• BitTornado (http://bt.degreez.net/) - Vidareutveckling av Shad0ws experimental, nu med kösystem och andra avancerade funktioner.
• G3 Torrent (http://g3torrent.sourceforge.net/)
• TorrenTopia (http://torrentopia.org/modules/news/)
• TorrentStorm (http://www.torrentstorm.com/)

Andra program

• Maketorrent (http://krypt.dyndns.org:81/torrent/maketorrent/) - Används för att skapa .torrent-filer

Externa länkar

• Officiell hemsida (http://bitconjurer.org/BitTorrent)
• Protokoll-specifikation (http://bitconjurer.org/BitTorrent/protocol.html)
• BT-FAQ (http://btfaq.com/serve/cache/1.html) (Vad är en faq?)
• Gameupdates.org (http://www.gameupdates.org) BitTorrentsida med spelpatchar, mods & demos.