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:

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