Una descrizione del protocollo DCC
Nota: Il più delle persone potrebbero probabilmente tralasciare questo file e guardare invece le specificazioni del CTCP le quali oltre ad aggiornare ed includere totalmente questo file, trattano anche altre argomentazioni relazionate. Ho tenuto questo file solamente per ragioni storiche.
Il primo commento che farei riguarda il fatto che il protocollo DCC non fu mai destinato ad essere supportabile da altri clients all’infuori di IRCII. Perciò non mi assumo alcuna responsabilità riguardo ad esse,in quanto difficile da rendere effettivo per altri clients.
Perché DCC?
Il DCC permette all’utente di prevalere su alcune limitazioni della rete di server IRC e avere in ultimo allo stesso tempo,connessioni chat sicure in un protocollo orientato ad IRC.
Per il trasferimento dati attraverso i clients, DCC usa connessioni dirette TCP. Non c’è nessun controllo per il flood, così i pacchetti possono essere spediti al massimo della velocità e non ci sono dipendenze dai link dei server (o carichi a loro imposti). In più,dal passaggio attraverso la rete IRC
del’inizio contatto della connessione DCC, è impossibile spiare i messaggi in DCC da parte degli operatori con server crackati.
Come?
Per una connessione DCC il socket iniziale è creato dalla parte che inizia (offre) la connessione.
Questo dovrebbe essere un socket TCP accoppiato a INADDR_ANY per captare le connessioni,
il client chiamante,nel creare il socket,potrebbe inviare i propri dettagli al client destinatario usando il comando CTCP DCC. Questo comando assume la forma:
DCC type argument address port
type - Il tipo di connessione
argument – L’argomento da cui dipende il collegamento
addres - L’indirizzo host tutto intero di chi ha iniziato la connessione.
port - La porta o il socket sulla quale l’iniziatore attende di ricevere la connessione
L’indirizzo e la porta dovrebbero essere inviati come rappresentazioni ascii del completo formato decimale in modo da convertire i valori in ordine di host byte e trattarli rispettivamente come an unsigned long and unsigned short.
I seguenti tipi di connessione sono conosciuti da IRCII:
| Type |
Scopo |
Argomento |
| CHAT |
per condurre una conversazione sicura |
la stringa”chat” |
| SEND |
per inviare un file al ricevente |
il nome del file |
In più i seguenti sono inclusi nel comando DCC di IRCII sebbene non trasmettono una richiesta DCC tramite IRC:
TALK stabilisce una connessione audio.
Esecuzioni
I tipi di connessione CHAT e SEND non dovrebbero essere accettati automaticamente in quanto questo creerebbe il potenziale per il terrorismo. Invece essi notificheranno all’utente che è stata fatta una proposta e consentono all’utente di accettarla.
Il ricevente dovrebbe avere la possibilità di rinominare il file inviato con il comando DCC SEND previa il ritrovamento di esso.
A seguire,i passaggi che ricorrerebbero nei clients:
Iniziante:
Comando DCC inoltrato.
- Crea un socket accoppiato a INADDR_ANY,porta 0,e lo rende passivo (un socket listening)
- Invia al ricevente attraverso CTCP una richiesta DCC fornendo l’indirizzo e la porta del socket.(Questo è idealmente preso dall’indirizzo della parte locale del socket a sua volta connesso ad un server. Questo è presumibilmente l’interfaccia sull’host più vicino al resto della net e deriva in un piccolo salto di instradamento nel caso di nodi sul percorso).
- Continua normalmente fino a quando viene ricevuta una connessione.
Su una connessione:
- accetta la connessione
- chiudi il socket passivo originale
- esegui l’operazione sul nuovo socket.
Accettante:
Richiesta CTCP DCC ricevuta.
Registra l’informazione riguardante la richiesta del DCC e notifica all’utente.
A questo punto,l’utente sarebbe abilitato ad arrestare(chiudere) la richiesta oppure ad accettarla.
La richiesta dovrebbe essere accettata con un comando che specifica al mittente tipo e argomento oppure un sottogruppo di questi dove non esiste alcuna ambiguità.
Se accettato, crea un socket TCP.
Connette il nuovo socket all’indirizzo ed alla porta forniti.
Esegue l’operazione attraverso il socket.
Dettagli specifici dei tipi
| CHAT |
I dati inviati attraverso una connessione chat dovrebbero essere inviati linea per linea senza alcun prefissi o comandi. La connessione CHAT finisce quando una delle parti inoltra il comando DCC CLOSE al loro client il quale fa in modo che venga chiuso il socket e le informazioni sulla connessione siano tralasciate. |
| FILE |
I dati sono inviati in pacchetti piuttosto che ammassati a modo di flusso. Questo permette alla connessione DCC SEND di continuare la dove una connessione FTP invece fallisce. La dimensione dei pacchetti è sul client e può essere impostata dall’utente. Piccoli pacchetti hanno una probabilità più alta di riuscita in caso di links deboli. Il ricevente dovrebbe riconoscere ogni pacchetto dalla la trasmissione del numero totale di byte ricevuti come non siglati,4 byte integri in ordine di byte network. L’inviante non dovrebbe continuare a trasmettere finche il ricevente non ha riconosciuto tutti i dati già trasmessi. In più,l’inviante non dovrebbe chiudere la connessione finchè l’ultimo byte non è stato riconosciuto dal ricevente. |
| |
Da notare che non è possibile per il ricevente dire se ha ricevuto l’intero file-solamente chi invia ha quella informazione,poiché IRCII non la riporta. Gli utenti generalmente verificano il trasferimento attraverso il controllo delle dimensioni del file. |
| |
Da notare anche che nessun provvedimento è preso per il trasferimento di testi. |
| |
La dimensione del blocco usato da IRCII è BIG_BUFFER_SIZE (1024).
Questo dovrebbe essere probabilmente rivisto e ridotto. |
Traduzione del documento in lingua originale a cura di :
Giandomenico "TiNtOrEtTo" Moioli tintoretto@ircitaly.net
Michele "M|[ck]3y" Bagnoli mickey@ircitaly.net
Ultima revisione: 27 Aprile 2004
Documento originale di By Troy Rollo (troy@plod.cbme.unsw.oz.au)
su: http://www.irchelp.org/irchelp/rfc/dccspec.html
|
DCC
