Ci sono diversi clienti BitTorrent e Tracker su I2P. Poiché l’indirizzamento I2P utilizza una destinazione anziché IP e porta, le modifiche richieste nel tracker e nel software client per operare su I2P sono minori. Queste modifiche sono specificate di seguito. Osservare attentamente le linee guida per la compatibilità con i precedenti client e tracker i2p.
Questa pagina specifica i dettagli del protocollo comune a tutti i clienti e gli inseguitori. Clienti e tracker specifici possono implementare altre funzioni o protocolli unici.
Le porte software client e tracker aggiuntive sono benvenute per i2p.
annunci
I clienti di solito includono una porta parametro falso = 6881 nell’annuncio, con la compatibilità con i precedenti tracker. I tracker possono ignorare il parametro PORT (PORT) e non dovrebbero averne bisogno.
Il parametro IP è la base 64 della destinazione del client, utilizzando la base I2P 64 – ~ alfabeto. Le destinazioni sono 387+ byte, con cui la base 64 è 516+ byte. I clienti generalmente aggiungono “.i2p” alla destinazione di base 64 per mantenere la compatibilità con i vecchi inseguitori. I tracker non dovrebbero essere necessari per aggiungere “.i2p” alla fine.
altri parametri sono uguali come nel BitTorrent standard.
Le destinazioni attuali I2P per i clienti sono 387 byte o più (516 o più con la codifica di base64). Un massimo ragionevole da assumere, per ora è 475 byte. Poiché il tracker deve decodificare la base64 per produrre risposte compatte (vedi sotto), probabilmente il tracker deve decodificare e rifiutare la base64 errata quando questo È annunciato.
La risposta del tipo predefinita non è compatta. I clienti possono richiedere una risposta compatta con il parametro Compact = 1. Un trackerpodría, ma non è un requisito, restituire una risposta compatta quando richiesto.
ai nuovi sviluppatori dei clienti I2P sono fortemente incoraggiati a implementare annunci pubblicitari sul proprio tunnel invece che sul proxy del client HTTP nella porta 4444. Ciò è tanto più efficiente e a sua volta consente al tracker di applicare destinazioni (vedi sotto).
Nessun cliente o tracker I2P conosciuto che attualmente supportano le risposte pubblicitarie / UDP.
Non -Compact Tracker risponde
La risposta non compatta è come il BitTorrent standard, con un “IP” I2P.
I tracker includono generalmente una chiave di falsa porta o utilizzare la porta pubblicitaria , per la compatibilità con i clienti precedenti. I clienti devono ignorare il parametro PORT (PORT) e non dovrebbe richiederlo.
Il valore del tasto IP è la base 64 della destinazione del client, come descritto sopra. I tracker generalmente aggiungono “.i2p” alla fine della destinazione di base 64 se non fosse sull’IP dell’AD, mediante compatibilità con i clienti precedenti. I clienti non dovrebbero richiedere un suffisso “.I2P” nelle risposte.
Altri tasti e valori di risposta sono gli stessi dello standard BitTorrent.
Compact Tracker risponde
Nella risposta compatta, il valore del tasto dizionario dei “peer” è una singola catena di byte, la cui lunghezza è un multiplo di 32 byte. Questa catena contiene hash SHA-256 di 32 byte concatenato dalle destinazioni peer binarie. Questo `Hash` (identificatore univoco) deve essere calcolato dal tracker, a meno che non utilizzi l’applicazione a destinazione (vedi sotto), nel qual caso l’identificatore (` hash`) consegnato nell’Http X-I2P-Deshash o X- Le intestazioni I2P -Destb32 possono essere convertite in binarie e memorizzate. La chiave delle coppie (`i peers`) può essere assente, oppure il valore delle coppie può avere lunghezza zero.
Sebbene il supporto per la risposta compatta sia opzionale per i client e gli inseguitori, è altamente Consigliato da quando riduce la dimensione nominale della risposta circa il 90%.
Applicazione a destinazione
Alcuni clienti torrent di I2P, anche se non tutti, annunciano i propri tunnel. I tracker possono scegliere di impedire l’ingresso impegnativo chiedendo loro e verificando la destinazione del cliente utilizzando le intestazioni aggiunte dal tunnel del server HTTP I2Punnel. Le intestazioni sono X-I2P-Denthash, X-I2P-DENTHERB64 e X-I2P-DESTB32, che sono diversi formati per le stesse informazioni. Queste intestazioni non possono essere distorte dal cliente. Le destinazioni che richiedono tracker non hanno bisogno del parametro dell’annuncio IP.
Poiché diversi client utilizzano il proxy HTTP invece dei propri tunnel per gli annunci pubblicitari, l’applicazione di destinazione (sul tracker) prevederà il suo utilizzo da parte di quelli I clienti a meno che, o fino a quando i clienti vengano ricominciati a pubblicizzare sui propri tunnel.
Sfortunatamente, coltivando la rete, lo farà anche la quantità di maliziosità, quindi speriamo che in quel momento tutti i tracker applicano le destinazioni. Entrambi, gli sviluppatori di tracker e i clienti devono anticiparlo.
Nomi del server di annuncio
I nomi dei server URL dell’annuncio nei file torrent, standard di follow-up dei nomi I2P. Oltre ai nomi del server dei libri di indirizzo e dei nomi dei server di base 32 “.b32.i2p”, deve essere supportata la destinazione di base completa 64 (con suffisso “.I2P”]. I tracker non aperti devono riconoscere il proprio server nomi in uno qualsiasi di questi formati.
Per preservare l’anonimato, i clienti dovrebbero solitamente ignorare gli URL di AD non I2P nei file torrent.
connessioni tra i client
-Per-customer Connections Utilizzare il protocollo standard su TCP. Attualmente non ci sono clienti I2P noti che supportano la comunicazione UTP (protocollo di trasporto uTorrent).
I2P USA Destinazioni di 387 + byte per le indicazioni, come spiegato sopra.
Se il client ha solo l’identificatore crittografico (`Hash`) della destinazione (come quella di una risposta compatta o del PEX (TEER Exchange Protocol)), è necessario eseguire una ricerca che la codifica con la base 32, aggiungendo il suffisso “.b32.i2p” e consulenza nel servizio del nome s, che restituirà la destinazione completa se è disponibile.
Se il cliente ha la destinazione completa di una coppia (`peer`) che ha ricevuto in una risposta non compatta, deve usarlo direttamente su l’istituzione della connessione. Non convertire una destinazione su un identificatore crittografico (`hash`) Base 32, questo è abbastanza inefficiente.
Prevenzione rossa incrociata.
Per preservare l’anonimato, i clienti I2P BitTorrent di solito non supporta annunci NO-I2P o collegamenti di accoppiamento (`Peers`). I proxy all’estero (outproxies`) HTTP da I2P spesso bloccano gli annunci. Nessun proxy all’estero prese conosciute che supportano il traffico bittorrent.
per impedire l’utilizzo dei clienti NO-I2P attraverso un proxy interiore (“Inproxy`) HttTT, I2P Tracker spesso bloccano l’accesso all’Hewer X- Inoltrato per. I tracker devono rifiutare gli annunci di rete standard con IPv4 o IPv6 e non consegnarli nelle risposte.
Il PEX (Pair Exchange Protocol) I2P si basa su UT_Pex (uTorrent PEX). Poiché non sembra essere una specifica formale UT_PEX, potrebbe essere necessario rivedere il codice sorgente libtororrent per assistenza. È un messaggio di estensione, identificato come “i2p_pex” nell’estensione del jack di contatto (`handshake`). Contiene un dizionario codificato B (`Bencoded`) con un massimo di 3 tasti,” aggiunto “,” aggiunto.f “e” caduto “(scartato). I valori “aggiunsero” e` caduto in una catena di un singolo byte, la cui dimensione è un multiplo di 32 byte. Queste catene di byte sono gli identificatori crittografici (“hash”) SHA-256 concatenati delle destinazioni peer binarie (`Parerie). Questo è lo stesso formato di quello dei valori del dizionario delle coppie nel formato di risposta Compact I2P specificato sopra. Se presente, il valore ADEDE.F è lo stesso di UT_Pex.
DHT
Il supporto DHT (Dynamic Hash Table) è incluso nel client I2PSNark dalla versione 0.9.2 . Le differenze preliminari con la BEP 5 (proposta di miglioramento di BitTorrent 5) sono descritte di seguito e sono soggette a modifiche. Contatta gli sviluppatori I2P Se si desidera sviluppare un cliente con il supporto DHT.
La difesa che DHT (tavolo Hash dinamico), I2P DHT non utilizza alcun bit nelle opzioni di contatto (`Handshake`) o nel messaggio della porta (porta). È annunciato con un messaggio di estensione, identificato come “i2p_dht” nell’estensione della handshake. Contiene un dizionario codificato B (`Bencoded`) con due chiavi,” Porta “e” Rport “, entrambi i numeri interi.
La porta UDP (datagramma) elencata nelle informazioni del nodo compatto viene utilizzata per ricevere replica (Firmato) DataGamps.Questo viene utilizzato per query, ad eccezione degli annunci. Chiamiamo questa la “porta della query”. Questo è il valore “porto” dal messaggio di estensione. Utilizzare il numero I2cprotocollo 17.
In Oltre a quella porta UDP, utilizziamo il secondo datagramport uguale alla porta della query + 1. Questo viene utilizzato per ricevere datagems (RAW) (RAW) per risposte, errore e annuncia. Questa porta fornisce un’efficienza incredibile poiché i tacchi di risposta inviati in query e necessità Non essere firmato. Chiamammo la “Porta di risposta”. Questo è il valore “Rport” dal messaggio di estensione. Deve essere 1 + la porta della query.Respons e annuncia l’uso del numero I2cprotocol 18.
Compact Le informazioni sulla coppia (`peer`) sono 32 byte (identificatore crittografico (` hash`) SHA256 32 Bytes) anziché 4 byte di IP + 2 Byte porta. Non c’è porto della coppia.In una risposta, il tasto “valori” (valori) è un elenco di catene, ciascuno contenente le informazioni compatte di una singola coppia.
Le informazioni del nodo compatto sono 54 byte (20 byte di hash sha1 + 32 Bytes of Hash SHA256 + 2 Byte porta) anziché 20 byte di hash sha1 + 4 byte di IP + 2 byte di porto. In una risposta, il tasto “nodi” (nodi) è una stringa singola byte con informazioni compattate di nodo compatizzato.
Identificatore requisito (`ID`) Nodo sicuro: per renderlo più differenti attacchi DHT diversi (distribuiti Tabella hash) I primi 4 byte dell’identificatore del nodo (`ID”) devono corrispondere ai primi 4 byte dell’identificatore crittografico (`Hash`) della destinazione, e i seguenti 2 byte dell’identificatore del nodo devono corrispondere al prossimo 2 Byte del risultato del funzionamento o esclusivo dell’hash con il porto.
In un file torrent, il tasto “nodi” dal dizionario di un torrent senza tracker deve essere determinato. Potrebbe essere un elenco di catene binarie a 32 byte (hash sha256) anziché un elenco di liste contenenti una catena server e un intero valore portuale. Alternative: una singola catena di byte con voti concatenata o un elenco di catene da solo.
datagrams tracker (UDP)
ancora non disponibile per i client e gli inseguitori (Trackers BitTorrent) supporto per i tracker UDP.Le differenze preliminari con BEP 15 sono descritte di seguito, e sono suscettibili di cambiare. Contatto con gli sviluppatori I2P Se si desidera sviluppare un cliente o un tracker che supporti annunci pubblicitari sui datagrammi.
A Tracker UDP ascolta 2 porte. La “Porta Petition” è la porta pubblicizzata e viene utilizzata per ricevere dati intermedibili (firmati), solo per la richiesta di connessione. La “Porta di risposta” è utilizzata per ricevere datagrammi senza firma (RAW, RAW) ed è il porto di origine per tutte le risposte. Il porto di risposta è arbitrario.a il cliente invia e riceve esclusivamente in un singolo porto. Non ha ancora segnalato). DATAGRAMS RAW PROCIPCION Nan maggiore efficienza per le risposte, poiché contengono credenziali inviate nella petizione e non devono essere firmate.
Nell’applicazione dell’annuncio, l’IP a 4 byte è sostituito da un hash di 32 byte, e la porta è ancora presente, sebbene possa essere ignorata dal tracker. Nella risposta dell’annuncio, ciascuna porta IP e 2 byte a 4 byte, viene sostituita da un hash (informazioni di coppia compatta) di 32- byte, senza presentare qualsiasi porta . Il client invia la richiesta di annuncio e la richiesta di raschi (raschiatura, statistiche del torrent) alla porta di origine del pacchetto di risposta dell’annuncio. Richiesta di connessione, risposta della connessione, risposta della connessione, risposta della connessione, la risposta di raschiatura, la risposta di raschino come nella (proposta di miglioramento bittorrent) BEP 15.
Gli indirizzi di origine in I2P non possono essere spuntati, quindi è possibile utilizzare un protocollo semplificato 2 pacchetti in prese di credito di 4, omettendo la richiesta di connessione e la risposta. questo caso, th La richiesta di annuncio è un datagramma di riproduzione inviato alla porta della query del tracker e il tracker non richiederebbe una porta di risposta. Questo è più efficiente, sarebbe più difficile modificare un tracker esistente per supportare questa modalità. L’URL per il Tracker a 4 pacchetti Utilizzerebbe il prefisso standard “UDP: //” standard. L’URL per un tracker modificato a 2 pacchetti richiederebbe un prefisso diverso se entrambe le modalità sono supportate in I2P.
Informazioni aggiuntive
- Gli standard BitTorrent I2P sono generalmente discussi in ZZZ.I2P.
- Un grafico con le funzionalità del software Tracker corrente è disponibile anche lì.
- il FAQ del BitTorrent I2P
- Discusione di DHT su I2P