BitTorrent Despre I2P

Această pagină a fost actualizată ultima dată în ianuarie 2017 și este exactă cu versiunea 0.9.28 a routerului i2p.

Există mai mulți clienți bitTorrent și de tracker pe i2p. Deoarece adresarea I2P utilizează o destinație în loc de IP și Port, modificările necesare în software-ul de tracker și client pentru a funcționa pe I2P sunt minore. Aceste modificări sunt specificate mai jos. Respectați cu atenție liniile directoare pentru compatibilitatea cu clienții anteriori și trackers I2P.

Această pagină specifică detalii despre protocolul comun tuturor clienților și trackerilor. Clienții și tracker-urile specifice pot implementa alte caracteristici sau protocoale unice.

Porturile de software de client și tracker suplimentare sunt binevenite pentru i2p.

Anunțuri

Clienții cu care includ, de obicei, un port de parametru fals = 6881 în anunț, prin compatibilitate cu trackere anterioare. Trackerele pot ignora parametrul port (port) și nu ar trebui să aibă nevoie de ea.

Parametrul IP este baza 64 a destinației clientului, utilizând alfabetul de bază I2P 64 – ~. Destinațiile sunt 387+ octeți, cu care baza 64 este de 516+ octeți. Clienții au adăugat în general „.2p” la destinația de bază 64 pentru a menține compatibilitatea cu tracker-urile vechi. Trackers nu ar trebui să aibă nevoie pentru a adăuga „.2P” la sfârșit.

Alți parametri sunt aceiași ca în standardul BitTorrent.

Destinațiile actuale ale I2P pentru clienți sunt 387 de octeți sau mai mult (516 sau mai mult cu codarea Base64). Un maxim rezonabil de presupus, pentru moment, este de 475 de octeți Este anunțat.

Răspunsul de tip implicit este neacact. Clienții pot solicita un răspuns compact cu parametrul compact = 1. Un trackerpodría, dar nu este o cerință, returnând un răspuns compact atunci când este solicitat Astfel, este la fel de eficient și, la rândul său, permite trackerului să aplice destinații (vezi mai jos).

Nu sunt clienți sau nu cunoscute de trackerele I2P care suportă în prezent răspunsurile la anunțuri / UDP.

Non -Compact de urmărire Răspunsuri

Răspunsul non-compact este ca standardul BitTorrent, cu un „IP” i2p.

Trackerele includ, în general, o cheie a portului fals sau folosiți portul publicitar , pentru compatibilitatea cu clienții anteriori. Clienții trebuie să ignore parametrul portului (port) și nu trebuie să-l solicite.

Valoarea cheii IP este baza 64 a destinației clientului, așa cum este descris mai sus. În general, trackerele se adaugă „.2P” la sfârșitul destinației de bază 64 dacă nu a fost pe adresa IP a anunțului, prin compatibilitatea cu clienții anteriori. Clienții nu ar trebui să solicite un sufix „.2p” în răspunsuri.

Alte taste și valorile de răspuns sunt aceleași ca în standardul BitTorrent.

Compact Tracker Răspunsuri

În răspunsul compact, valoarea dicționarului cheie a „colegilor” este un lanț unic de octeți, a cărui lungime este un multiplu de 32 de octeți. Acest lanț conține hashes SHA-256 din 32 de octeți concatenați din destinațiile binare de la egal la egal. Acest „identificator unic) trebuie calculat de tracker, cu excepția cazului în care utilizează aplicația la destinație (a se vedea mai jos), caz în care identificatorul (” hash „) livrat în HTTP x-i2p-Desthash sau X- Antetele I2P -DESTB32 poate fi transformat în binar și stocat. Cheia perechilor („colegii”) poate fi absentă sau valoarea perechilor poate avea o lungime zero.

Deși suportul pentru răspunsul compact este opțional atât pentru clienți, cât și pentru tracker, este foarte Recomandat, deoarece reduce dimensiunea nominală de răspuns la aproximativ 90%.

Aplicație la destinație

Unii clienți torrenți ai I2P, deși nu toți, anunță propriile tuneluri. Trackerele pot alege să prevină înșelăciunea prin cererea lor și verificarea destinației clientului utilizând antetele adăugate de tunelul serverului HTTP I2ptunnel. Anteturile sunt X-I2P-Denthash, X-i2p-Dentb64 și X-I2P-DESTB32, care sunt diferite formate pentru aceleași informații. Aceste anteturi nu pot fi distorsionate de client. O destinație exigentă de urmărire nu are nevoie de parametrul anunțului IP.

Întrucât mai mulți clienți utilizează proxy HTTP în loc de propriile lor tuneluri pentru reclame, aplicația de destinație (pe tracker) va împiedica utilizarea acestuia de către acestea Clienții cu excepția cazului în care sau până când clienții nu sunt recondiționați pentru a face publicitate pe propriile tuneluri.

Din păcate, prin creșterea rețelei, va face, de asemenea, cantitatea de răutate, așa că sperăm că, la momentul în care toate trackerele aplică destinații. Ambele, dezvoltatorii de tracker și clienții trebuie să anticipeze acest lucru.

Numele serverului de anunțuri

Numele serverului de anunț de anunțare în fișiere torrent, standarde de urmărire a numelor i2p. În plus față de numele serverului cărților de adrese și numele serverului de bază 32 „.b32.i2p”, trebuie să fie sprijinită destinația de bază integrală 64 (cu sufixul „.i2p”]. Trackerele non-deschise trebuie să-și recunoască propriul server nume în oricare dintre aceste formate.

Pentru a păstra anonimatul, clienții ar trebui, de obicei, să ignore adresele adresă de anunțuri non-i2p în fișierele torrent.

conexiuni între clienți

client – Conexiunile cu clienții utilizează protocolul standard pe TCP. În prezent, nu există clienți I2P cunoscuți care sprijină comunicarea UTP (protocolul de transport uTorrent).

i2p SUA Destinații de 387 + octeți pentru instrucțiuni, după cum sa explicat mai sus.

Dacă clientul are doar identificatorul criptografic („Hash”) al destinației (cum ar fi cel al unui răspuns compact sau al PEX (Protocol de la Peer Exchange)), trebuie să efectuați o căutare care îl codifică cu baza 32, adăugând sufixul „.b32.i2p”, și consultanță în serviciul de nume S, care va returna destinația completă dacă este disponibilă.

Dacă clientul are destinația completă a unui cuplu („Peer”), a primit într-un răspuns non-compact, el trebuie să-l folosească direct pe stabilirea conexiunii. Nu convertiți o destinație înapoi la un identificator criptografic („hash”) 32, acest lucru este destul de ineficient.

prevenirea încrucișată roșie

pentru a păstra anonimatul, clienții i2p BitTorrent, de obicei, nu acceptă anunțuri NO-I2P sau conexiuni pereche („colegi”). Proxurile din străinătate (outproxies „) HTTP din I2P blochează adesea anunțurile. Nu există proxy-uri în străinătate prize cunoscute care susțin traficul bittorrent.

Pentru a preveni utilizarea de către clienții NO-I2P printr-o proxy interne („inprixi”) HTTTT, trackere i2p bloc blocează anunțurile de acces care conțin un antet HTTP X- Transmise pentru. Trackerele trebuie să respingă anunțurile de rețea standard cu IPv4 sau IPv6 și să nu le livreze în răspunsuri.

PEX (Pair Exchange Protocol) i2p se bazează pe UT_PEX (UTorrent PEX). Deoarece nu pare să existe o specificație formală UT_PEX, poate fi necesar să se revizuiască codul sursă libatorrent pentru asistență. Este un mesaj de extensie, identificat ca „i2p_pex” în extensia de contact (`Handshake”). Acesta conține un dicționar B-codificat („bencodat”) cu până la 3 taste, „Adăugat”, „Adăugat.f” și „a scăzut” (aruncat). Valorile „adăugate” și „au scăzut” sunt fiecare un singur lanț occit, a cărui dimensiune este un multiplu de 32 de octeți. Aceste lanțuri octetice sunt identificatorii criptografici („hashes”) SHA-256 concatenizează destinațiile binare de la egal (`colegii). Acesta este același format ca și cea a valorilor dicționarului perechilor din formatul de răspuns compact I2P specificat mai sus. Dacă este prezent, valoarea ADEDE.F este aceeași ca în UT_PEX.

DHT

Suportul DHT (tabelul dinamic Hash) este inclus în client i2psnark de la versiunea 0.9.2 . Diferențele preliminare cu BEP 5 (Propunerea de îmbunătățire a BitTorrent 5) sunt descrise mai jos și pot fi modificate. Contactați dezvoltatorii i2P dacă doriți să dezvoltați un client cu suport DHT.

apărarea pe care DHT (tabelul dinamic Hash), I2P DHT nu utilizează niciun pic în opțiunile de contact („Handshake”) sau în mesajul port (port). Acesta este anunțat cu un mesaj de extensie, identificat ca „i2p_dht” în extensia Handshake. Acesta conține un dicționar B-codificat („bencodat”) cu două chei, „port” și „rport”, ambele numere întregi.

Portul UDP (Datagram) enumerat în informațiile compacte de nod este folosit pentru a primi replica (Semnat) DatagAmpss.Acest lucru este folosit pentru interogări, cu excepția anunțurilor.We numim acest „portul de interogare”. Acest lucru este valoarea „port” de la mesajul de extensie.Queries Utilizați I2Cprotocol Numărul 17.

în Adăugarea la acel port UDP, folosim cel de-al doilea DatagramPort egal cu Portul de interogare + 1. Acest lucru este utilizat pentru a primi (brut) Datagems pentru răspunsuri, eroare și anunță. Acest port oferă o eficiență increditată de la repreligontain tokens trimise în interogare și au nevoie Să nu fiți semnat. Sunăm acest „portul de răspuns”. Acest lucru este valoarea „rport” din mesajul de extensie. Trebuie să fie 1 + portul de interogare și anunță utilizarea i2cprotocolului numărul 18.

Compact Informațiile despre cuplu („peer”) sunt de 32 de octeți (identificator criptografic („Hash”) SHA256 32 bytes) în loc de 4 octeți de IP + 2 Port Bytes. Nu există nici un port de pereche.La un răspuns, cheia „valorile” este o listă de lanțuri, fiecare conținând informațiile compacte ale unei singure perechi.

Informațiile compacte ale nodului sunt de 54 de octeți (20 de octeți de Hash SHA1 + 32 Bytes of Hash SHA256 + 2 PORT Bytes) în loc de 20 octeți de hash SHA1 + 4 octeți de IP + 2 octeți de port. Într-un răspuns, cheia „noduri” (noduri) este un șir de byte cu informații compatibile compatibile.

Cerință de identificare (`id`) Nod sigur: pentru a face mai dificil diferite atacuri DHT (distribuite Tabelul Hash) Primele 4 octeți ai identificatorului nodului (id „) trebuie să se potrivească primilor 4 octeți ai identificatorului criptografic (` hash „) de destinație, iar următorii 2 octeți ai identificatorului nodului trebuie să se potrivească cu următorul 2 octeți de rezultatul funcționării sau exclusiv a hashului de destinație cu portul.

Într-un fișier torrent, cheia „noduri” din dicționarul unui torrent fără tracker trebuie să fie determinată. Ar putea fi o listă cu lanțuri binare de 32 de octeți (hashes SHA256) în locul unei liste de liste care conțin un lanț de servere și o valoare totală a portului. Alternative: un singur lanț de octeți cu grade concatenate sau o listă de lanțuri singur.

Datagrams trackers (UDP)

încă nu este disponibil pentru clienți și trackers (Trackers BitTorrent) pentru trackers UDP. Diferențele preliminare cu BEP 15 sunt descrise mai jos și sunt susceptibile de a se schimba. Contactați-vă cu dezvoltatorii i2P dacă doriți să dezvoltați un client sau un tracker care acceptă reclame despre Datagrams.

un UDP de tracker ascultă 2 porturi. „Portul Petition” este portul publicitar și este utilizat pentru a primi date responsabile (semnate), numai pentru solicitarea de conexiune. „Portul de răspuns” este utilizat pentru a primi Datagrams fără semnare (RAW, RAW) , și este portul sursă pentru toate răspunsurile. Portul de răspuns este arbitrar.a clientul trimite și primește exclusiv într-un singur port. Nu a semnalat încă). Datagrams Propincionii prime Nan o mai mare eficiență pentru răspunsuri, deoarece acestea conțin acreditări trimise în petiție și nu trebuie să fie semnate.

În cererea de anunțuri, IP-ul 4-octet este înlocuit cu un hash de 32 de octeți, iar portul este încă prezent, deși poate fi ignorat de tracker. În răspunsul la anunțuri, fiecare port IP 4 octet și 2-byte, este înlocuit cu o hash (informații compacte de cuplu) de 32 de octeți, fără a prezenta niciun port . Clientul trimite solicitarea de anunțuri și solicitarea de răzuire a portului sursă a pachetului de răspuns la anunțuri. Cerere de conectare, Răspuns de conectare, Răspuns la conexiune, Răspuns de conexiune Scăderea, Răspunsul lui Shape și răspuns de eroare, sunt La fel ca în (Propunerea BitTorrent Îmbunătățire) BEP 15.

Adresele sursă în i2p nu pot fi spofeale, deci este posibil să se utilizeze un protocol simplificat 2 pachete INSEAD de 4, omiterea cererii de conectare și a răspunsului acest caz, th E anunțați cererea ar fi o datagramă replemente trimise la portul de interogare al trackerului, iar trackerul nu ar necesita un port de răspuns. În timp ce acest lucru este mai eficient, ar fi mai dificil să modificați un tracker existent pentru a susține acest mod. URL-ul pentru Tracker-ul cu 4 pachete ar folosi prefixul standard „UDP: //”. URL-ul pentru un tracker modificat cu 2 pachete ar necesita un prefix diferit dacă ambele moduri sunt acceptate în i2p.

Informații suplimentare

  • Standardele I2P BitTorrent sunt, în general, discutate în Zzz.i2p.
  • Un grafic cu capabilitățile software-ului curent de tracker este, de asemenea, disponibil acolo.
  • Întrebări frecvente ale BitTorrent i2p
  • DISCUZUȚIA DHT DESPRE I2P

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *