Luni, 7 septembrie 2020 de arvid

libtorrent-2.0 tocmai a fost lansat cu câteva caracteristici noi majore. Unul dintre ele este suportul pentru BitTorrent v2.

Cea mai mare parte a lucrărilor de specificații ale BEP 52 au fost realizate de către8472. Suportul libtorrent pentru bittorrent v2 a fost implementat în cea mai mare parte de Steven Siloti. BiglyBT are, de asemenea, o implementare a BitTorrent v2 care va fi lansată în viitorul apropiat.

BitTorrent v2 a început cu un efort de a trece de la SHA-1 ca funcție hash pentru piese, la scurt timp după ce Google a anunțat că a produs o coliziune. Având în vedere că o nouă funcție hash nu ar fi compatibilă cu versiunile anterioare, au fost propuse și alte câteva modificări, în timp ce oricum luam succesul de compatibilitate. Această postare descrie noile caracteristici ale protocolului BitTorrent v2.

SHA-256

Funcția hash pentru datele pieselor a fost schimbată în SHA-256. O consecință a acestui fapt este că hashurile sunt de 32 de octeți în loc de 20 de octeți. În BitTorrent v2, dicționarul de informații este de asemenea calculat de SHA-256, ceea ce reprezintă o provocare de compatibilitate cu DHT și trackere, care au protocoale care așteaptă hashuri de 20 de octeți. Pentru a gestiona acest lucru, DHT- și tracker anunță și căutări pentru torrentele v2 folosesc SHA-256 info-hash trunchiat la 20 de octeți.

Acesta a fost unul dintre motivele originale pentru crearea unui protocol v2 pentru început. Înseamnă că, în mod fundamental, un torrent v2 va fi identificat printr-un hash diferit decât un torrent v1, care ar crea întotdeauna un roi separat, chiar și atunci când partajează aceleași fișiere. Mai multe despre acest lucru mai târziu, în conformitate cu compatibilitatea inversă.

copaci hash

În BitTorrent v1, piesele sunt hashate și hashurile rezultate sunt incluse în fișierul/metadatele .torrent (în dicționarul de informații). În majoritatea cazurilor, hash-ul piesei reprezintă cea mai mare parte a dimensiunii fișierelor .torrent. Pentru a menține dimensiunea fișierului .torrent în limita motivului pentru fișierele mari, dimensiunea piesei poate fi mărită, ceea ce înseamnă că fiecare hash reprezintă o porțiune mai mare a fișierului. O consecință a dimensiunilor mari ale pieselor este că, dacă un hash eșuează, trebuie să descărcați din nou o porțiune mai mare a fișierului, până când piesa trece de verificarea hash.

O idee veche pentru a îmbunătăți ambele metrici este de a folosi arbori de hasle merkle pentru a reprezenta hash-ul piesei (inițial implementat în tribler). Acest lucru păstrează fișierele .torrent mici, deoarece tot ce aveți nevoie este hashul rădăcină al copacului. BitTorrent v2 folosește arborii de hasle merkle pentru piese (dar un protocol diferit pe care cel implementat). Aceasta are următoarele avantaje:

  • Metadatele torrent (în special porțiunea info-dicționar a unui fișier .torrent) devin mult mai mici. Acest lucru elimină latența de pornire la adăugarea unui link magnetic, deoarece mai puțini octeți trebuie descărcați înainte ca descărcarea torrent să poată începe.
  • Datele descărcate pot fi validate la nivel de bloc. Adică dacă un partener trimite date corupte, acesta poate fi descoperit imediat și doar 16 kiB trebuie re-descărcați. Partenerul care a trimis datele corupte poate fi, de asemenea, identificat cu certitudine. Aceasta este o mare îmbunătățire față de euristicile necesare pentru a identifica peerul rău din v1, uneori denumit smart-ban.

Frunzele copacilor sunt întotdeauna 16 kiB (dimensiunea blocului), indiferent de dimensiunea piesei. Conceptul de dimensiune a piesei există încă și este încă folosit în protocolul peer-wire așa cum este astăzi. de exemplu. în mesajele HAVE și CERERE. Cu toate acestea, în loc ca hash-ul piesei să fie de fapt hash-ul conținutului piesei, este rădăcina arborelui hash al piesei. adică un sub-copac al arborelui complet merkle.

În v2, fișierul .torrent trebuie să conțină în continuare aceste hashuri de piese (într-adevăr hashurile din arborele merkle reprezentând nivelul piesei). Acest lucru ajută la distribuirea și stocarea hashurilor, astfel încât acestea să nu fie recomputate la repornirea unui client care este însămânțat. De asemenea, sunt stocate în starea CV. Dimensiunea fișierului .torrent nu este mai mică pentru un torrent v2, deoarece conține încă hash-ul piesei, dar este informația-dicționar, care este partea necesară pentru ca linkurile magnet să înceapă descărcarea.

hash-ul piesei

Exemplu de arbore pentru un fișier cu 4 blocuri și o dimensiune a piesei de 32 kiB (2 blocuri pe bucată)

arbori hash per fișier

BitTorrent v2 nu numai că folosește un arbore hash, dar formează un arbore hash pentru fiecare fișier din torrent. Acest lucru are câteva avantaje:

  • Fișierele identice vor avea întotdeauna același hash și pot fi mutate mai ușor de la un torrent la altul (atunci când creează torrent) fără a fi nevoie să re-hash nimic. Fișierele identice pot fi, de asemenea, identificate mai ușor în diferite roiuri, deoarece hashul lor rădăcină depinde doar de conținutul fișierului.
  • Toate fișierele vor fi aliniate în bucăți, ceea ce înseamnă că există fișiere implicite de pad după fiecare fișier

Aceasta abordează dorința de lungă durată de a identifica mai ușor fișierele duplicat sau de a găsi mai multe surse pentru fișiere, între roiuri.

structura directorului

Așa cum am menționat mai devreme, de cele mai multe ori fragmentele ocupă majoritatea spațiului din dicționarul de informații. Excepțiile sunt torrentele cu o mulțime de fișiere mici; atunci este lista de fișiere care folosește cel mai mult spațiu. În torrentele v1, listele de fișiere sunt exprimate ca o listă unică de fișiere cu căi complete. Într-un torrent cu o structură de directoare profundă (sau doar directoare cu nume lungi), acele nume de directoare vor fi duplicate de mai multe ori, agravând problema.

Torentele v2 abordează acest lucru utilizând o codificare mai eficientă pentru structura de directoare, cu mai puține duplicări. În loc de o listă plană, structura directorului este stocată ca un copac (folosind dicționare codificate). Acest lucru duce la denumirile de directoare menționate o singură dată. De exemplu:

Comparativ cu arborele de fișiere v2 (acesta include și hashurile rădăcinii arborelui merkle):

dimensiunea piesei

În torrentele v1, dimensiunea unei piese nu este restricționată de specificație. Nu are prea mult sens să ai o piesă mai mică decât dimensiunea blocului de 16 kiB, dar nu este interzisă. Marea majoritate a torrentelor care sunt create folosesc o putere de două dimensiuni, dar există câteva valori aberante care nu sunt, dar sunt încă divizibile cu 16 kiB. Torentele v2 întăresc cerințele dimensiunilor pieselor, cerându-le să fie:

  • o putere de doi
  • mai mare sau egal cu 16 kiB

Motivul principal pentru aceasta este faptul că hashurile pentru piese se potrivesc în copacii de hash. Deoarece hash-urile v2 sunt într-adevăr rădăcina arborelui de hasle merkle al piesei, trebuie să reprezinte un număr de blocuri de putere de două.

codificare

Un fișier .torrent este o structură de arbore codificată cu codificare bencodată. În bencoding există câteva cazuri de valori unice cu multiple codificări posibile. Un număr întreg ar putea fi codat cu zerouri inițiale sau nu, 0 ar putea fi codificat ca negativ 0. Aceste codificări au fost întotdeauna ilegale, dar analizoarele au fost în mod istoric îngăduitoare și le-au acceptat. Poate cel mai frecvent exemplu este modul în care tastele din dicționare trebuie să fie sortate lexicografic. Cu toate acestea, unii creatori de torrent nu au reușit să le sorteze, astfel încât clienții le-au acceptat.

Acest lucru cauzează în primul rând probleme la declanșarea rotundă a unei structuri codificate. Odată analizat, ordinea specifică a intrărilor de dicționar sau numărul specific de zero-uri anterioare se poate pierde. Deci, atunci când recodificați structura, aceasta poate fi diferită. Dacă dicționarul care este rotunjit este dicționarul informațional, informația hash s-a schimbat și lucrurile se vor rupe.

libtorrent aplică acum aceste restricții refuzând să încarce orice torrent v2 care conține:

  • un număr întreg cu zero zero (cu excepția 0 în sine). de exemplu. „I0004e”
  • un 0 codificat ca -0. adică. „I-0e”
  • un dicționar în care intrările nu sunt sortate corect. de exemplu. „D1: B3: foo1: A3: gol” („A” ar trebui să fie sortat înainte de „B”)

Aplicarea acestor codificări ajută, de asemenea, la creșterea probabilității ca două persoane care creează un torrent din aceleași fișiere să ajungă cu același info-hash și același torrent.

legături magnetice

Protocolul magnet link a fost extins pentru a suporta torrentele v2. Ca urna: btih: prefix pentru v1 SHA-1 info-hashes, există un nou prefix, urna: btmh: pentru v2 complet SHA0256 informații hash. De exemplu, o legătură magnetică arată astfel:

Info-hash cu prefixul btmh este v2 info-hash în format multi-hash codificat în hexazecimal. În practică, aceasta înseamnă că va avea un prefix de doi octeți 0x12 0x20. Este posibil să se includă ambii un hash-info v1 (btih) și v2 (btmh) într-un link magnetic, pentru compatibilitate inversă.

compatibilitate înapoi

Toate noile funcții din BitTorrent v2 care nu sunt compatibile cu versiunile anterioare au primit cu atenție nume noi, pentru a le permite să coexiste cu omologii v1. Prin urmare, este posibil să creați torrente hibride. Adică, torrente care pot participa atât la un roi v1, cât și la un v2 simultan, servind aceleași fișiere.

Un torrent hibrid are două informații-hash, un v1 SHA-1 hash unul (posibil trunchiat) SHA-256 hash. Aceasta formează două roiuri sau un roi separat. libtorrent marchează colegii ca suport pentru v2 sau nu. Aceste informații sunt, de asemenea, transmise prin intermediul unui nou indicator de schimb peer (PEX).

Un fișier .torrent hibrid include atât hash-uri de piese, cât și hash-uri de rădăcină de copac pentru fiecare fișier.

testarea

Pentru oricine este interesat să testeze o implementare BitTorrent v2 (sau un client care utilizează libtorrent-2.0), puteți găsi torrente de testare aici:

Un torrent hibrid (compatibil cu versiunile anterioare)

O implementare de referință a unui creator de torrent în python.

Postat în protocol | Fara comentarii