Linea principale DHT - Mainline DHT

Mainline DHT è il nome dato alla tabella hash distribuita (DHT) basata su Kademlia utilizzata dai client BitTorrent per trovare i peer tramite il protocollo BitTorrent . L'idea di utilizzare un DHT per il monitoraggio distribuito è stata implementata per la prima volta in Azureus 2.3.0.0 (ora noto come Vuze ) nel maggio 2005, da cui ha guadagnato una notevole popolarità. Non correlato ma nello stesso periodo, BitTorrent, Inc. ha rilasciato un DHT simile nel proprio client chiamato Mainline DHT, e quindi ha reso popolare l'uso del tracciamento distribuito nel protocollo BitTorrent . La misurazione mostra che nel 2013 gli utenti di Mainline DHT vanno da 10 milioni a 25 milioni, con un tasso di abbandono giornaliero di almeno 10 milioni.

Descrizione

Mainline DHT si basa sul popolare design Kademlia DHT . Prima dell'utilizzo di un DHT per la distribuzione dei peer, i tracker erano l'unico metodo per trovare i peer. La caratteristica chiave dell'utilizzo del DHT sui tracker è che l'approccio decentralizzato favorisce la natura del protocollo BitTorrent. Il DHT opera distribuendo elenchi di peer identificati dall'hash SHA-1 del torrent.

operazione

L'hash SHA-1 di un torrent, l' infohash , è sinonimo di una chiave Kademlia, utilizzata per trovare peer (valori) nella rete overlay. Per trovare i peer in uno sciame, un nodo invia una query get_peers con l'infohash come chiave (equivalente a un Kademlia FIND_VALUE ) ai nodi conosciuti più vicini (rispetto alla distanza della chiave). Come Kademlia, se il nodo non restituisce il valore (peers), persiste ulteriormente in un'operazione iterativa. Tuttavia, una volta esaurita la ricerca, il client inserisce anche le informazioni di contatto del peer per se stesso sui nodi di risposta con ID più vicini all'infohash del torrent.

Gettone

I nodi utilizzano una misura aggiuntiva nota come token per garantire che altri non registrino altri host per i torrent. Il valore restituito per una query per i peer include questo valore opaco. Affinché un nodo annunci che il suo peer di controllo sta scaricando un torrent, deve presentare il token ricevuto dallo stesso nodo interrogato in una query recente per i peer. Quando un nodo tenta di "annunciare" un torrent, il nodo interrogato confronta il token con l'indirizzo IP del nodo interrogante.

Mainline DHT utilizza l'hash SHA1 dell'indirizzo IP concatenato su un segreto che cambia ogni cinque minuti per un valore token. Sono accettati token fino a dieci minuti di età.

KRPC

Un nodo nel Mainline DHT è costituito da una combinazione di IP e porta. I nodi comunicano tramite un protocollo RPC - KRPC. KRPC è un semplice protocollo che consiste in nodi che inviano messaggi (query, risposte ed errori) contenenti dizionari BEncoded su UDP .

Un messaggio KRPC è un singolo dizionario con due chiavi comuni a ogni messaggio e chiavi aggiuntive a seconda del tipo di messaggio. Ogni messaggio ha una chiave "t" con un valore di stringa che rappresenta un ID di transazione. Questo ID transazione viene generato dal nodo di query e viene riprodotto nella risposta, quindi le risposte possono essere correlate a più query allo stesso nodo. L'ID transazione deve essere codificato come una breve stringa di numeri binari, in genere sono sufficienti 2 ottetti poiché coprono 2^16 query in sospeso. L'altra chiave contenuta in ogni messaggio KRPC è "y" con un singolo valore di carattere che descrive il tipo di messaggio. Il valore della chiave "y" è uno tra "q" per query, "r" per risposta o "e" per errore.

Interrogazioni

Le query, o dizionari di messaggi KRPC con un valore "y" di "q", contengono due chiavi aggiuntive; "q" e "a". La chiave "q" ha un valore stringa contenente il nome del metodo della query. La chiave "a" ha un valore di dizionario contenente argomenti denominati per la query.

Risposte

Le risposte, o dizionari di messaggi KRPC con un valore "y" di "r", contengono una chiave aggiuntiva "r". Il valore di "r" è un dizionario contenente valori di ritorno denominati. I messaggi di risposta vengono inviati al completamento con successo di una query.

Errori

Errori, o dizionari di messaggi KRPC con un valore "y" di "e", contengono una chiave aggiuntiva "e". Il valore di "e" è un elenco. Il primo elemento è un numero intero che rappresenta il codice di errore. Il secondo elemento è una stringa contenente il messaggio di errore. Gli errori vengono inviati quando una query non può essere soddisfatta.

Tabella di routing

I secchi sono strutturati in modo diverso da quelli di Kademlia. Invece di un elenco di 160 bucket, BitTorrent inizia con un solo bucket. Quando un secchio si riempie, possono accadere due cose:

  1. Il secchio è diviso
  2. Viene eseguito il ping dei vecchi nodi (come in Kademlia)

La suddivisione è un'operazione che si verifica solo se il nostro ID nodo rientra nell'intervallo del bucket. Il bucket che viene diviso viene sostituito da due nuovi bucket ciascuno con metà dell'intervallo del vecchio bucket e i nodi del vecchio bucket vengono distribuiti tra i due nuovi.

Ci sono 2 vantaggi per questa implementazione del bucket:

  • Viene utilizzata meno memoria per una tabella di routing con meno di 160 bucket
  • Durante la ricerca nei bucket, non è necessario recuperare nodi aggiuntivi dai bucket adiacenti perché è garantito che ce ne siano a sufficienza nel bucket corrente

Estensione del protocollo BitTorrent

Il protocollo BitTorrent è stato anche esteso per scambiare i numeri di porta UDP del nodo tra i peer introdotti da un tracker. In questo modo, i client possono ottenere il seeding automatico delle tabelle di routing tramite il download di torrent regolari. I client appena installati che tentano di scaricare un torrent trackerless al primo tentativo non avranno nodi nella loro tabella di routing e avranno bisogno dei contatti inclusi nel file torrent.

I peer che supportano il DHT impostano l'ultimo bit dei flag riservati a 8 byte scambiati nell'handshake del protocollo BitTorrent. Il peer che riceve un handshake che indica che il peer remoto supporta il DHT deve inviare un messaggio PORT. Inizia con il byte 0x09 e ha un payload di due byte contenente la porta UDP del nodo DHT nell'ordine dei byte di rete. I peer che ricevono questo messaggio dovrebbero tentare di eseguire il ping del nodo sulla porta ricevuta e sull'indirizzo IP del peer remoto. Se viene ricevuta una risposta al ping, il nodo dovrebbe tentare di inserire le nuove informazioni di contatto nella propria tabella di instradamento secondo le normali regole.

Torrent

Un dizionario torrent senza tracker non ha un tasto "annuncio" . Invece, un torrent senza tracker ha una chiave "nodes" , che funziona come un elenco di nodi Bootstrapping (nel caso in cui non ci siamo già uniti alla rete overlay). Questa chiave è normalmente impostata sui nodi K più vicini nella tabella di routing del client che genera il torrent.

È stato anche introdotto ufficiosamente un flag "privato" , che dice ai clienti di limitare l'uso del tracciamento decentralizzato indipendentemente dai desideri dell'utente. Il flag viene posizionato intenzionalmente nella sezione info del torrent in modo che non possa essere disabilitato o rimosso senza modificare l'identità del torrent. Lo scopo del flag è impedire la condivisione di torrent con client che non hanno accesso al tracker.

implementazioni

Mainline DHT è stato incluso per la prima volta nella versione 4.2.0 di BitTorrent (software) (novembre 2005). Da allora, è stato implementato da numerosi altri clienti:

Riferimenti

link esterno