Connessione diretta avanzata - Advanced Direct Connect
| Connessione diretta avanzata | |
|---|---|
| Versione protocollo: 1.0.3 | |
| Versione di estensione 1.0.8 | |
| http://www.adc.sourceforge.net | |
| Protocollo | |
| Estensioni | |
Advanced Direct Connect ( ADC ) è un protocollo di chat e condivisione di file peer-to-peer , che utilizza la stessa topologia di rete , concetti e terminologia del protocollo Direct Connect (DC).
"ADC", acronimo non ufficiale di "Advanced Direct Connect".
Storia
ADC è stato creato per consentire un protocollo estensibile e per risolvere alcune carenze del protocollo Direct Connect . È stato avviato da Jacek Sieka , sotto l'influenza del progetto DCTNG di Jan Vidar Krey . La prima revisione di ADC è arrivata nel 2004 e la prima versione ufficiale nel 2007-12-01.
Design e caratteristiche
ADC è strutturato attorno a client che si connettono a un hub centrale, dove i client (utenti) possono chattare e scaricare file da altri client (utenti). L'hub fornisce il routing tra i client per chat, ricerche e richieste di connessioni. I trasferimenti di file effettivi avvengono tra i client.
Il protocollo stesso è diviso in due parti: un protocollo di base che ogni client e hub devono rispettivamente seguire e estensioni che sono opzionali. I protocolli consentono la segnalazione delle funzionalità del protocollo (come i filtri bloom ) e i messaggi possono essere costruiti per essere instradati solo a coloro che supportano quella particolare funzionalità.
Ogni hub ha le proprie regole e sono comunemente governati dagli operatori di hub. Gli hub possono definire funzionalità diverse per gli operatori di hub. Gli hub stessi non regolano discussioni e file, ma gli operatori degli hub. L'hub regola la quota minima e la quantità massima di hub simultanei; cose che vengono inviate dal client, piuttosto che dall'utente.
Esistono elenchi di hub in cui vengono specificati il nome, la descrizione, l'indirizzo e le regole di un hub. Con l'elenco hub, gli utenti possono scegliere hub simili in base alle preferenze dell'utente per argomenti e file di discussione.
La parte peer-to-peer del protocollo si basa sul concetto di "slot" (simile al numero di posizioni aperte per un lavoro). Questi slot indicano il numero di persone che possono scaricare da un utente in qualsiasi momento. Gli slot sono controllati dall'utente del rispettivo client.
ADC richiede che tutto il testo venga inviato in UTF-8 , il che significa che gli utenti con codifiche di sistema diverse (ad esempio, russo e cinese) possono chattare con i rispettivi caratteri nativi.
Il protocollo supporta nativamente IPv6 .
Ci sono due modalità in cui un utente può trovarsi: "attivo" o "passivo". I client in modalità attiva possono eseguire il download da chiunque altro sulla rete. Gli utenti in modalità passiva possono eseguire il download solo da utenti attivi. I client passivi riceveranno i risultati della ricerca tramite l'hub, mentre i client attivi riceveranno i risultati direttamente. Un ricercatore attivo riceverà (al massimo) 10 risultati per utente e un ricercatore passivo riceverà (al massimo) 5 risultati per utente. L'attraversamento NAT esiste come estensione del protocollo, che consente agli utenti passivi di connettersi ad altri utenti passivi.
Il protocollo di base non richiede la crittografia , ma esistono estensioni per fornire la crittografia con TLS .
I file nelle connessioni client sono identificati dal loro hash , più comunemente Tiger Tree Hash . L'algoritmo hash viene negoziato con l'hub e utilizzato durante la sessione client-hub, nonché le successive connessioni client-client.
Protocollo
Il protocollo ADC è un protocollo basato su testo, in cui i comandi e le relative informazioni vengono inviati in testo non crittografato, tranne durante la negoziazione della password. L'aspetto client-server (così come client-client, dove si agisce come un "server") del protocollo prevede che il client parli per primo quando è stata stabilita una connessione. Ad esempio, quando un client si connette al socket di un hub, il client è il primo a parlare con l'hub.
Il protocollo richiede che tutto il testo debba essere inviato come Unicode codificato UTF-8 , normalizzato nella forma C.
Non ci sono impostazioni di porta predefinite, per hub o client.
Gli indirizzi hub hanno la seguente forma: adc: //example.com: 411, dove 411 è la porta.
Durante lo scambio di informazioni sul protocollo hub-client, il client offre una serie di hash che supporta. L'hub selezionerà uno di questi hash e tale hash verrà utilizzato durante la sessione hub-client. Se l'hub ritiene che il client non supporti un set di hash appropriato (arbitrario), viene generato un errore.
Lo schema di identificazione globale si basa sul set di hash che produce due hash finali, in cui uno dipende dall'output dell'altro. Durante lo scambio di informazioni tra hub e client, il client invierà questi hash finali, codificati con base32, che l'hub confermerà per la corrispondenza. Uno di questi hash con codifica base32 verrà ulteriormente inviato ad altri client nella rete. Lo schema di identificazione globale è quest'ultima stringa. Il client può modificare i propri hash finali su base da hub a hub.
A ogni utente, durante una sessione hub, viene assegnato un hash che dura solo quella particolare sessione. Questo hash verrà utilizzato per tutti i riferimenti client in quell'hub. Non c'è dipendenza dai nick.
Ogni notifica di informazioni sul cliente viene inviata in modo incrementale.
Una richiesta in arrivo per una connessione client-client è collegata a una connessione effettiva, con l'utilizzo di un token.
Le ricerche utilizzano anche un token per identificare ogni risultato di una ricerca.
Non esiste una capacità immediata per un client di cacciare o reindirizzare un altro client da un hub. L'hub, tuttavia, può kickare e reindirizzare arbitrariamente. L'hub può anche richiedere che tutti gli altri client nell'hub terminino i loro trasferimenti con il client espulso / reindirizzato. Se un client viene reindirizzato a un altro hub, il client di reindirizzamento deve utilizzare un referrer, simile al referrer HTTP . Il client espulso / reindirizzato non è tenuto a ricevere un messaggio di notifica.
La parte peer-to-peer del protocollo si basa sul concetto di "slot" (simile al numero di posizioni aperte per un lavoro). Questi slot indicano il numero di persone che possono scaricare da un utente in qualsiasi momento. Questi slot sono controllati dal client. L'allocazione automatica degli slot è supportata dal protocollo.
Il token nella connessione client-client decide chi deve essere autorizzato a scaricare per primo.
I download vengono trasportati tramite TCP. Le ricerche possono essere trasportate utilizzando TCP o UDP.
Un client attivo ha una porta di ascolto per TCP e un'altra per UDP, sebbene le porte non dipendano l'una dall'altra.
I delimitatori di protocollo sono "\ n" e "" (spazio). Il carattere "\" viene utilizzato come sequenza di escape. Le sequenze di escape consentite sono "\ n" (nuova riga), "\ s" (spazio) e "\\" (barra rovesciata).
Il protocollo consente estensioni come la compressione con bzip2 o la crittografia con TLS . Sebbene il protocollo non imponga l'implementazione di queste estensioni, gli hub potrebbero richiederle.
Guarda anche
Riferimenti
- ^ Fredrik Ullner (marzo 2007). "ADC: The run down" . DC ++: Solo questi ragazzi, sai? blog . Estratto 2010-12-13 .
- ^ Jan Vidar Krey (agosto 2006). "ADC: semplicità del protocollo" . Jan Vidar Krey. Archiviata dall'originale il 30 gennaio 2013 . Estratto 2006/09/23 .
- ^ Fredrik Ullner (marzo 2006). "Potenza + Persona = Operatore" . DC ++: Solo questi ragazzi, sai? blog . Estratto 2010-12-13 .
- ^ Fredrik Ullner (gennaio 2007). "Le parti di un elenco hub" . DC ++: Solo questi ragazzi, sai? blog . Estratto 2010-12-13 .
- ^ Fredrik Ullner (marzo 2006). "Slot, slot, slot ..." . DC ++: Solo questi ragazzi, sai? blog . Estratto 2010-12-13 .
- ^ Fredrik Ullner (dicembre 2010). "Estensioni ADC - NATT - NAT traversal" . Progetto ADC . Estratto 2010-12-13 .
- ^ Fredrik Ullner (dicembre 2010). "Estensioni ADC - ADCS - Crittografia simmetrica in ADC" . Progetto ADC . Estratto 2010-12-13 .
- ^ En_Dator (marzo 2009). "TLS e crittografia" . ADCPortal. Archiviata dall'originale il 7 luglio 2011 . Estratto 2009-03-01 .
