Mainline DHT

Mainline DHT är namnet på den Kademlia -baserade distribuerade hashtabellen (DHT) som används av BitTorrent-klienter för att hitta peers via BitTorrent -protokollet. Idén att använda en DHT för distribuerad spårning i BitTorrent implementerades först i Azureus 2.3.0.0 (nu känd som Vuze ) i maj 2005, från vilken den fick betydande popularitet. Orelaterat men ungefär samtidigt släppte BitTorrent, Inc. en liknande DHT i sin klient som heter Mainline DHT, och på så sätt populariserade användningen av distribuerad spårning i BitTorrent-protokollet. Mätningar visade att 2013 är det samtidiga antalet användare av Mainline DHT från 16 miljoner till 28 miljoner, med förändringar under dagen på minst 10 miljoner.

Beskrivning

Mainline DHT är baserad på den populära Kademlia DHT- designen. Före användningen av en DHT för att distribuera kamrater spårare den enda metoden för att hitta kamrater. Nyckelfunktionen med att använda DHT över spårare är att det decentraliserade tillvägagångssättet gynnar BitTorrent-protokollets natur. DHT fungerar genom att distribuera listor över kamrater som identifieras av torrentens SHA-1- hash.

Drift

SHA-1-hash för en torrent, infohash , är synonymt med en Kademlia-nyckel, som används för att hitta peers (värden) i överlagringsnätverket. För att hitta peers i en svärm skickar en nod en get_peers- fråga med infohash som nyckel (motsvarande en Kademlia FIND_VALUE ) till de närmaste kända noderna (med avseende på nyckelavståndet). Liksom Kademlia, om noden inte returnerar värdet (peers), kvarstår den vidare i en iterativ operation. Men efter att sökningen är slut, infogar klienten också peer-kontaktinformationen för sig själv på de svarande noderna med ID:n närmast torrentens infohash.

Tecken

Noder använder en extra åtgärd som kallas en token för att säkerställa att andra inte registrerar andra värdar för torrents. Returvärdet för en fråga för peers inkluderar detta ogenomskinliga värde. För att en nod ska meddela att dess styrande peer laddar ner en torrent, måste den presentera token som tagits emot från samma frågade nod i en ny fråga för peers. När en nod försöker "annonsera" en torrent, kontrollerar den förfrågade noden token mot den frågande nodens IP-adress.

Mainline DHT använder SHA-1-hash för IP-adressen sammanfogad till en hemlighet som ändras var femte minut för ett tokenvärde. Poletter upp till tio minuter gamla accepteras.

KRPC

En nod i Mainline DHT består av en IP- och portkombination. Noder kommunicerar via ett RPC -protokoll som kallas KRPC . KRPC är ett enkelt protokoll som består av noder som skickar meddelanden (frågor, svar och fel) som innehåller benkodade ordböcker över UDP .

Ett KRPC-meddelande är en enda ordbok med två nycklar som är gemensamma för varje meddelande och ytterligare nycklar beroende på typen av meddelande. Varje meddelande har en nyckel "t" med ett strängvärde som representerar ett transaktions-ID. Detta transaktions-ID genereras av den frågande noden och återges i svaret, så svar kan korreleras med flera frågor till samma nod. Transaktions-ID:t bör kodas som en kort sträng av binära tal, vanligtvis räcker två oktetter eftersom de täcker 2^16 utestående frågor. Den andra nyckeln som finns i varje KRPC-meddelande är "y" med ett enda teckenvärde som beskriver typen av meddelande. Värdet på "y" -nyckeln är ett av "q" för fråga, "r" för svar eller "e" för fel.

Frågor

Frågor, eller KRPC-meddelandeordböcker med ett "y"-värde på "q", innehåller ytterligare två nycklar; "q" och "a". Nyckeln "q" har ett strängvärde som innehåller metodnamnet för frågan. Nyckel "a" har ett ordboksvärde som innehåller namngivna argument till frågan.

Svar

Svar, eller KRPC-meddelandeordböcker med ett "y"-värde på "r", innehåller ytterligare en nyckel "r". Värdet på "r" är en ordbok som innehåller namngivna returvärden. Svarsmeddelanden skickas efter framgångsrikt slutförande av en fråga.

Fel

Fel, eller KRPC-meddelandeordböcker med ett "y"-värde på "e", innehåller ytterligare en nyckel "e". Värdet på "e" är en lista. Det första elementet är ett heltal som representerar felkoden. Det andra elementet är en sträng som innehåller felmeddelandet. Fel skickas när en fråga inte kan uppfyllas.

Routningstabell

Skopor är strukturerade annorlunda än de i Kademlia. Istället för en lista på 160 hinkar, börjar BitTorrent med endast en hink. När en hink blir full kan en av två saker hända:

Hinken är delad.
Gamla noder pingas (som i Kademlia).

Splittring är en operation som endast sker om vårt eget nod-ID faller inom intervallet för hinken. Skopan som delas ersätts av två nya skopor vardera med halva räckvidden av den gamla skopan och noderna från den gamla skopan är fördelade på de två nya.

Det finns två fördelar med denna hinkimplementering:

Mindre minne används för en routingtabell på mindre än 160 hinkar.
När du söker efter hinkar är det inte nödvändigt att hämta ytterligare noder från intilliggande hinkar eftersom det garanteras att det finns tillräckligt med i den aktuella hinken.

Genomföranden

Mainline DHT inkluderades först i version 4.2.0 av programvaran BitTorrent (november 2005). Sedan dess har det implementerats av ett antal andra kunder:

externa länkar