Conectare directă avansată - Advanced Direct Connect
| Conexiune directă avansată | |
|---|---|
| Versiune protocol: 1.0.3 | |
| Extensie Versiunea 1.0.8 | |
| http://www.adc.sourceforge.net | |
| Protocol | |
| Extensii | |
Advanced Direct Connect ( ADC ) este un protocol de partajare de fișiere și chat peer-to-peer , utilizând aceeași topologie de rețea , concepte și terminologie ca protocolul Direct Connect (DC).
„ADC” neoficial un acronim pentru „Advanced Direct Connect”.
Istorie
ADC a fost creat pentru a permite un protocol extensibil și pentru a remedia unele neajunsuri ale protocolului Direct Connect . A fost inițiată de Jacek Sieka , sub influența proiectului DCTNG al lui Jan Vidar Krey . Prima revizuire a ADC a venit în 2004 și prima versiune oficială în 01.12.2007.
Design și caracteristici
ADC este structurat în jurul clienților care se conectează la un hub central, unde clienții (utilizatorii) pot conversa prin chat și descărca fișiere de la alți clienți (utilizatori). Hubul oferă rutare între clienți pentru chat, căutări și solicitări de conexiuni. Transferurile reale de fișiere sunt între clienți.
Protocolul în sine este împărțit în două părți: un protocol de bază pe care fiecare client și respectiv hub trebuie să îl urmeze și extensii care sunt opționale. Protocoalele permit semnalizarea caracteristicilor protocolului (cum ar fi filtrele bloom ), iar mesajele pot fi construite pentru a fi direcționate numai către cei care acceptă acea caracteristică specială.
Fiecare hub are propriile reguli și sunt guvernate în mod obișnuit de operatorii de hub. Hub-urile pot defini diferite capacități pentru operatorii de hub-uri. Huburile în sine nu reglementează discuțiile și fișierele, ci operatorii de hub. Hubul reglementează cota minimă și cantitatea maximă de hub-uri simultane; lucruri care sunt trimise de client, mai degrabă decât de utilizator.
Există liste de hub-uri în care sunt specificate numele, descrierea, adresa și regulile unui hub. Cu lista de hub-uri, utilizatorii pot alege hub-uri care sunt similare în funcție de dorința utilizatorului de subiecte și fișiere de discuție.
Partea peer-to-peer a protocolului se bazează pe un concept de „sloturi” (similar cu numărul de posturi deschise pentru un loc de muncă). Aceste sloturi indică numărul de persoane cărora li se permite să descarce de la un utilizator în orice moment. Sloturile sunt controlate de către utilizatorul respectivului client.
ADC cere ca tot textul să fie trimis în UTF-8 , ceea ce înseamnă că utilizatorii cu codificare de sistem diferită (de exemplu, rusă și chineză) pot conversa prin chat cu caracterele native respective.
Protocolul acceptă nativ IPv6 .
Există două moduri în care poate fi utilizat un utilizator: „activ” sau „pasiv”. Clienții în modul activ pot descărca de la oricine altcineva din rețea. Utilizatorii modului pasiv pot descărca numai de la utilizatorii activi. Clienților pasivi li se vor trimite rezultatele căutării prin hub, în timp ce clienții activi vor primi rezultatele direct. Un căutător activ va primi (cel mult) 10 rezultate per utilizator și un căutător pasiv va primi (cel mult) 5 rezultate per utilizator. Traversarea NAT există ca o extensie de protocol, care permite utilizatorilor pasivi să se conecteze la alți utilizatori pasivi.
Protocolul de bază nu necesită criptare , dar există extensii pentru a asigura criptarea cu TLS .
Fișierele din conexiunile clientului sunt identificate prin hash - ul lor , cel mai frecvent Tiger Tree Hash . Algoritmul hash este negociat cu hub-ul și utilizat pe parcursul sesiunii client-hub, precum și conexiunile client-client ulterioare.
Protocol
Protocolul ADC este un protocol bazat pe text, unde comenzile și informațiile lor sunt trimise în text clar, cu excepția negocierii cu parolă. Aspectul client-server (precum și client-client, unde se acționează ca un „server”) al protocolului stipulează că clientul vorbește mai întâi atunci când s-a făcut o conexiune. De exemplu, atunci când un client se conectează la socket-ul unui hub, clientul este primul care vorbește cu hub-ul.
Protocolul impune ca tot textul să fie trimis ca Unicode codificat UTF-8 , normalizat în forma C.
Nu există valori implicite pentru porturi , pentru hub-uri sau clienți.
Adresele hub sunt sub următoarea formă: adc: //example.com: 411, unde 411 este portul.
În timpul schimbului de informații de protocol hub-client, clientul oferă un set de hash-uri pe care le acceptă. Hubul va selecta unul dintre aceste hashuri, iar acel hash va fi utilizat pe parcursul sesiunii hub-client. Dacă hub-ul consideră că clientul nu acceptă un set hash adecvat (arbitrar), se generează o eroare.
Schema de identificare globală se bazează pe setul de hash care produce două hash-uri finale, unde unul dintre ele depinde de ieșirea celuilalt. În timpul schimbului de informații hub-client, clientul va trimite aceste hash-uri finale, codificate cu base32, pe care hub-ul le va confirma că se potrivesc. Unul dintre aceste hash-uri codificate base32 va fi trimis în continuare către alți clienți din rețea. Schema globală de identificare este acest ultim șir. Clientul își poate schimba hash-urile finale pe bază hub-to-hub.
Fiecărui utilizator, în timpul unei sesiuni hub, i se atribuie un hash care durează doar acea sesiune anume. Acest hash va fi utilizat pentru toate referințele clienților din acel hub. Nu există dependență de nicks.
Fiecare notificare de informații despre client este trimisă în mod incremental.
O cerere de intrare pentru o conexiune client-client este legată de o conexiune reală, cu utilizarea unui simbol.
Căutările folosesc și un simbol, pentru a identifica fiecare rezultat al unei căutări.
Nu există nicio abilitate prealabilă pentru ca un client să trimită sau să redirecționeze un alt client dintr-un hub. Cu toate acestea, hub-ul poate lovi și redirecționa în mod arbitrar. Hubul poate solicita, de asemenea, ca toți ceilalți clienți din hub să își încheie transferurile cu clientul lovit / redirecționat. Dacă un client este redirecționat către un alt hub, clientul de redirecționare trebuie să utilizeze un referrer, similar cu referrerul HTTP . Clientul lovit / redirecționat nu este obligat să primească un mesaj de notificare.
Partea peer-to-peer a protocolului se bazează pe un concept de „sloturi” (similar cu numărul de posturi deschise pentru un loc de muncă). Aceste sloturi indică numărul de persoane cărora li se permite să descarce de la un utilizator în orice moment. Aceste sloturi sunt controlate de client. Alocarea automată a sloturilor este acceptată de protocol.
Jetonul din conexiunea client-client decide cui ar trebui să i se permită mai întâi descărcarea.
Descărcările sunt transportate utilizând TCP. Căutările pot fi transportate folosind TCP sau UDP.
Un client activ are un port de ascultare pentru TCP și altul pentru UDP, deși porturile nu depind unele de altele.
Delimitatorii de protocol sunt „\ n” și „(spațiu). Caracterul „\” este folosit ca o secvență de evadare. Secvențele de evacuare permise sunt „\ n” (linie nouă), „\ s” (spațiu) și „\\” (bară inversă).
Protocolul permite extensii precum compresia cu bzip2 sau criptarea cu TLS . Deși protocolul nu impune ca aceste extensii să fie implementate, hub-urile ar putea să le solicite.
Vezi si
Referințe
- ^ Fredrik Ullner (martie 2007). "ADC: Eroarea în jos" . DC ++: Doar acești băieți, știți? blog . Adus 13-12-2010 .
- ^ Jan Vidar Krey (august 2006). "ADC: simplitatea protocolului" . Jan Vidar Krey. Arhivat din original la 30.01.2013 . Adus 23-09-2006 .
- ^ Fredrik Ullner (martie 2006). „Puterea + Persoana = Operator” . DC ++: Doar acești băieți, știți? blog . Adus 13-12-2010 .
- ^ Fredrik Ullner (ianuarie 2007). "Părțile unei liste de hub-uri" . DC ++: Doar acești băieți, știți? blog . Adus 13-12-2010 .
- ^ Fredrik Ullner (martie 2006). "Sloturi, sloturi, sloturi ..." . DC ++: Doar acești băieți, știți? blog . Adus 13-12-2010 .
- ^ Fredrik Ullner (decembrie 2010). "Extensii ADC - NATT - traversare NAT" . Proiect ADC . Adus 13-12-2010 .
- ^ Fredrik Ullner (decembrie 2010). "Extensii ADC - ADCS - Criptare simetrică în ADC" . Proiect ADC . Adus 13-12-2010 .
- ^ En_Dator (martie 2009). „TLS și criptare” . ADCPortal. Arhivat din original pe 07-07-2011 . Adus 01-03-2009 .