Hi ha diversos clients bittorrent i trackers sobre I2P. Com el direccionament de I2P fa servir un Destí en lloc d’IP i port, els canvis que es requereixen en els programaris de el tracker i de el client per operar sobre I2P són menors. Aquests canvis s’especifiquen sota. Observi amb cura les directrius per compatibilitat amb anteriors clients i trackers I2P.
Aquesta pàgina especifica detalls de l’protocol comuns a tots els clients i trackers. Els clients i trackers específics poden implementar altres característiques úniques o protocols.
Són benvinguts ports addicionals de programari de client i tracker per I2P.
Anuncis
Els clients generalment inclouen un paràmetre fals port = 6881 a l’anunci, per compatibilitat amb anteriors trackers. Els trackers poden ignorar el paràmetre port (port), i no haurien de necessitar-ho.
El paràmetre IP és la base 64 de la Destinació de el client, usant l’alfabet I2P Base 64 – ~. Les Destinacions són de 387+ bytes, de manera que la Base 64 és de 516+ bytes. Els clients generalment afegeixen “.i2p” a la Destinació Base 64 per mantenir la compatibilitat amb els trackers antics. Els trackers no haurien necessitar afegir “.i2p” a al final.
Altres paràmetres són els mateixos que en el bittorrent estàndard.
Els actuals destinacions I2P per a clients són de 387 bytes o més (516 o més amb codificació Base64) .Un màxim raonable a assumir, per ara, és 475 bytes.Como el tracker ha de descodificar la Base64 per produir respostes compactes (vegi sota), probablement el tracker ha de descodificar i rebutjar la Base64 errònies quan això s’anunciï.
La resposta tipus per defecte és no-compacta. Els clients poden sol·licitar una resposta compacta amb el paràmetre compact = 1. Un trackerpodría, però no és un requisit, tornar una resposta compacta cuandose li sol·liciti.
Als desenvolupadors de nous clients I2P se’ls anima fortament a implementar anuncis sobre el seu propi túnel en lloc de sobre el proxy de client HTTP al port 4444. Fer-ho així és tant més eficient com al seu torn permet a l’tracker aplicar destinacions (vegi sota).
No hi ha clients o trackers I2P coneguts que actualment suporten anuncis / respostes UDP.
Respostes de tracker no-compactes
la resposta no-compacta és com la de l’bittorrent estàndard, amb una “ip” I2P.
Els trackers generalment inclouen un clau de port falsa, o usen el port de l’anunci, per compatibilitat amb anteriors clients. Els clients han d’ignorar el paràmetre port (port), i no han de sol·licitar-.
El valor de la clau ip és la base 64 de la Destinació de el client, com es descriu anteriorment. Els trackers generalment afegeixen “.i2p” a la fi de la Destinació Base 64 si no era al ip de l’anunci, per compatibilitat amb anteriors clients. Els clients no han de demanar un sufix “.i2p” en les respostes.
Altres claus i valors de resposta són els mateixos que en el bittorrent estàndard.
Respostes de tracker compactes
En la resposta compacta, el valor de la clau de diccionari dels “peers” (parells) és una única cadena de bytes, la longitud és un múltiple de 32 bytes. Aquesta cadena conté els hashes SHA-256 de 32-bytes concatenats de l’binari Destinacions dels parells. Aquest `hash` (identificador únic) s’ha de calcular pel tracker, llevat que usi aplicació en destí (vegi sota), i en aquest cas l’identificador (` hash`) lliurat en les capçaleres HTTP X-I2P-DestHash o X-I2P -DestB32 pot ser convertit a binari i emmagatzemat. La clau dels parells ( `peers`) pot estar absent, o el valor dels parells pot tenir longitud-zero.
Tot i que el suport per resposta compacta és opcional per a tots dos, clients i trackers, és altament recomanable ja que redueix la mida nominal de resposta voltant d’un 90%.
Aplicació en destí
Alguns clients de torrent de I2P, encara que no tots, anuncien els seus propis túnels. Els trackers poden triar el prevenir enganys exigint, i verificant la Destinació dels clients usant les capçaleres afegides pel túnel servidor HTTP I2PTunnel. Les capçaleres són X-I2P-DestHash, X-I2P-DestB64, i X-I2P-DestB32, que són diferents formats per a la mateixa informació. Aquestes capçaleres no poden ser falsejades pel client. Un tracker exigint destinacions no necessita el paràmetre d’anunci de la ip per a res.
Com diversos clients usen el servidor intermediari HTTP en lloc dels seus propis túnels per als anuncis, l’aplicació de destí (en el tracker) previndrà el seu ús per aquells clients llevat que, o fins que, aquells clients es reconverteixin per anunciar-se sobre els seus propis túnels.
Malauradament, a l’créixer la xarxa, també ho farà la quantitat de maliciosidad, així que esperem que en el seu moment tots els trackers apliquin les destinacions. Tots dos, desenvolupadors de trackers i clients han anticipar.
Noms de Servidor d’Anunci
Els noms de servidor d’URL d’anunci en els arxius torrent siguengeneralmente els estàndards de noms I2P. A més dels noms de servidor de les llibretes d’adreces i els nom de servidor Base 32 “.b32.i2p”, el Destí Base 64 complet (amb sufix “.i2p”] ha de ser suportat. Els trackers no-oberts han de reconèixer els seus propis noms de servidor en qualsevol d’aquests formats.
per preservar l’anonimat, els clients en general han d’ignorar URL d’anunci no-I2P en els fitxers torrent.
Connexions entre clients
Les connexions client-a-client usen el protocol estàndard sobre TCP. Actualment no hi ha clients I2P coneguts que suporten comunicació uTP (protocol de Transport utorrent).
I2P fa servir Destinacions de 387 + bytes per direccions, com es va explicar a dalt.
Si el client té només l’identificador criptogràfic ( `hash`) de la destinació (com el d’una resposta compacta o el PEX (protocol d’Intercanvi de Pares)) , ha de realitzar una recerca codificándolo amb Base 32, afegint el sufix “.b32.i2p”, i consultant en el Servei de Nom s, que tornarà el Destí complet si està disponible.
Si el client té el Destí complet d’un parell ( `peer`) que va rebre en una resposta no-compacta, ha de fer-lo servir directament en l’establiment de la connexió. No converteixi una Destinació de tornada a un identificador criptogràfic ( `hash`) Base 32, això és bastant ineficient.
Prevenció de xarxes-creuades.
Per preservar l’anonimat, els clients I2P bittorrent en general no suporten anuncis no-I2P, o connexions de parells ( `peers`). Els intermediaris a l’exterior ( `outproxies`) HTTP de I2P amb freqüència bloquegen anuncis. No hi ha proxys a l’exterior SOCKS coneguts que suportin trànsit bittorrent.
Per prevenir l’ús per clients no-I2P a través d’un intermediari cap a l’interior ( `inproxy`) HTTP, els trackers I2P sovint bloquegen accessos o anuncis que continguin una capçalera HTTP X-Forwarded-For. Els trackers han de rebutjar anuncis de xarxa estàndard amb IPs IPv4 o IPv6, i no lliurar-los en les respostes.
PEX
El PEX (protocol d’Intercanvi de Pares) I2P està basat en ut_pex (utorrent PEX). Com no sembla haver-hi una especificació ut_pex formal disponible, pot ser necessari revisar el codi font de libtorrent per obtenir assistència. És un missatge d’extensió, identificat com “i2p_pex” en l’extensió de presa de contacte ( `handshake`). Conté un diccionari b-codificat ( `bencoded`) amb fins a 3 claus,” added “(afegit),” added.f “, i” dropped “(descartat). Els valors `added` i` dropped` són cadascun una única cadena de bytes que pesa un múltiple de 32 bytes. Aquestes cadenes de bytes són els identificadors criptogràfics ( ‘hashes’) SHA-256 concatenats de l’binari Destinacions dels parells ( `peers`). Aquest és el mateix format que el dels valors de diccionari dels parells en el format de resposta compacta de I2P especificat dalt. Si està present, el valor de added.f és el mateix que en ut_pex.
DHT
El suport DHT (taula de hash dinàmica) està inclòs en el client i2psnark des de la versió 0.9.2. Les diferències preliminars amb la BEP maig (Proposta de Millora de Bittorrent 5) estan descrites sota, i estan subjectes a canvis. Contacti amb els desenvolupadors de I2P si vol desenvolupar un client amb suport DHT.
A l’contrari que DHT (taula de hash dinàmica), I2P DHT no fa servir bit algun en les opcions de presa de contacte ( `handshake` ), o al missatge pORT (port). S’anuncia amb un missatge d’extensió, identificat com “i2p_dht” en l’extensió handshake. Conté un diccionari b-codificat ( `bencoded`) amb dues claus,” port “i” rport “(port de resposta), tots dos sencers.
The UDP (Datagram) port listed in the compact node info is usedto receive repliable (signed) datagrams.This is used for queries, except for announces.We call this the “query port” .This is the “port” value from the extension message.Queries faci servir I2CPprotocol number 17.
in addition to that UDP port, we use a second datagramport equal to the query port + 1. This is used to receiveunsigned (raw) datagrams for replies, errors, and announces.This port provides Increased efficiency since repliescontain tokens vaig sentir in the query, and need not be signed.We call this the “response port” .This is the “rport” value from the extension message.It must be 1 + the query port.Responses and announces faci servir I2CPprotocol number 18.
La informació compacta de el parell ( `peer`) són 32 bytes (identificador criptogràfic (` hash`) SHA256 32 bytes) en lloc de 4 bytes d’IP + 2 bytes de port. No hi ha port de el parell.En una resposta, la clau “values” (valors) és una llista de cadenes, contenint cadascuna la informació compacta d’un únic parell.
La informació de node compacte són 54 bytes (20 bytes de hash SHA1 + 32 bytes de hash SHA256 + 2 bytes de port) en lloc de 20 bytes de hash SHA1 + 4 bytes d’IP + 2 bytes de port. En una resposta, la clau “nodes” (nodes) és una única cadena de bytes amb la informació concatenada de node compacte.
Requisit d’identificador ( `ID`) de node segur: Per fer més difícils diferents atacs DHT (taula de hash distribuïda) els primers 4 bytes de l’identificador de node ( `ID`) han de coincidir amb els primers 4 bytes de l’identificador criptogràfic (` hash`) de la destinació, i els següents 2 bytes de l’identificador de node han de coincidir amb els següents 2 bytes de l’resultat de l’operació OR-exclusiu de l’hash de la destinació amb el port.
En un fitxer torrent, la clau “nodes” de l’diccionari d’un torrent sense tracker ha de ser determinada. Podria ser una llista de cadenes binàries de 32 bytes (hashes SHA256) en lloc d’una llista de llistes que continguin una cadena de servidor i un valor sencer de port. Alternatives: Una única cadena de bytes amb hashes concatenats, o una llista de cadenes per si soles.
Trackers de datagrames (UDP)
Encara no està disponible per a clients i trackers (rastrejadors bittorrent) el suport per trackers UDP.Las diferències preliminars amb la (proposta de millora de bittorrent) BEP 15están descrites sota, i són susceptibles de cambiar.Contacte amb els desenvolupadors de I2P si vol desenvolupar un client o un tracker que suporti anuncis sobre datagrames .
Un tracker UDP escolta en 2 puertos.El “port de petició” és el port publicitat, i s’usa per rebre datagrames respondibles (signats), únicament per a la sol·licitud de conexión.El “port de resposta “s’usa per rebre datagrames sense signar (raw, en cru), i és el port font per a totes les respuestas.El port de resposta és arbitrario.Un client envia i rep exclusivament en un únic puerto.Únicamente rep datagrames sense signar (raw ) .Els datagrames raw proporcional nen una major eficiència per a les respostes, ja que contenen credencials enviades en la petició, i no necessiten estar signats.
En la sol·licitud d’anunci, la IP de 4-bytes és reemplaçada per un hash de 32- bytes, i el port encara està present, encara que pot ser ignorat pel tracker.En la resposta d’anunci, cada IP de 4-bytes i port de 2-bytes, és reemplaçat per un hash (informació compacta de el parell) de 32- bytes, sense presentar cap puerto.El client envia la sol·licitud d’anunci, i la sol·licitud de scrape (rascat, estadístiques de l’torrent) a el port font de l’paquet de resposta de anuncio.La petició de connexió, la resposta de connexió, la petició de scrape, la resposta de scrape, i la resposta d’error, són els mateixos que en la (proposició de millora de bittorrent) BEP 15.
Source addresses in I2P can not be spoofed, sota it is possible to use a simplified protocolwith 2 packets instead of 4, omitting the connect request and response.In this case, th i announce request would be a repliable Datagram vaig sentir to the tracker ‘s query port, and the tracker would not require a response port.While this is more efficient, it would be more difficult to modify an existing tracker to support this mode.The URL for the 4-packet-mode tracker would use standard “udp: //” prefix.The URL for a modified 2-packet-mode tracker would requereix a different prefix if both modes are supported in I2P.
Informació addicional
- Els estàndards bittorrent I2P es discuteixen generalment en zzz.i2p.
- Una gràfica amb les capacitats de l’actual programari de tracker també està disponible.
- l’FAQ de l’bittorrent I2P
- Discussió de DHT sobre I2P