Direct Client-to-Client

Direct Client-to-Client (DCC) is een sub-protocol van IRC-related dat het 2 gebruikers mogelijk maakt een peer-to-peer verbinding op te zetten. Het maakt alleen gebruik van de IRC-server voor het opzetten van de verbinding, maar als de verbinding eenmaal gemaakt is, gaat deze verder los van de server. Oorspronkelijk werd het gebruikt in IrcII, maar nu wordt het door veel IRC-clients ondersteund.

DCC-verbindingen kunnen op twee manieren opgezet worden:

• De gebruikelijke manier is om CTCP te gebruiken om een DCC-sessie op te zetten. De CTCP-aanvraag wordt via het IRC-netwerk van een naar een andere gebruiker gestuurd.
• Een andere manier is dat een client direct met een DCC-server verbindt. Op deze manier hoeven beide partijen niet met een IRC-netwerk verbonden te zijn.

De CHAT-service maakt het mogelijk dat gebruikers met elkaar praten (Chatten) over een DCC-verbinding. Het verkeer gaat direct tussen de gebruikers, in plaats van over het IRC-netwerk. Dit vermindert het verkeer op de IRC-netwerken en maakt het mogelijk grote berichten direct heen en weer te sturen, waar dat op IRC-netwerken vaak verboden is (Flood control). Ook is de verbinding veiliger omdat de IRC-servers hem niet zien. De verbinding is echter nog steeds in platte tekst.

DCC CHAT wordt normaal geïnitialiseerd met een CTCP handshake. De gebruiker die de verbinding op wil zetten zendt het volgende CTCP-commando naar het doel:

DCC CHAT <protocol> <ip> <poort> 

waar <ip> en <poort> het IP-adres en de poort die van de zender zijn, uitgedrukt als integers. <protocol> is altijd "chat". De ontvangende partij verbindt vervolgens met de gegeven poort en adres.

Als een verbinding eenmaal gemaakt is, is het DCC CHAT-protocol heel simpel: Gebruikers wisselen CRLF-beëindigde berichten uit.

De SEND-service maakt het mogelijk voor gebruikers om elkaar bestanden te verzenden. In de oorspronkelijke standaard voor de handshake wist de ontvanger de bestandsgrootte niet, ook was het niet mogelijk om een verbinding te hervatten. Vervolgens hebben vele clients uitbreidingen op de standaard geïntroduceerd, die intussen wijd verspreid zijn.

In de oorspronkelijke handshake verzond de zender het volgende CTCP-commando naar de ontvanger:

DCC SEND <bestandsnaam> <ip> <poort> 

Zoals met DCC CHAT zijn <ip> en <poort> het ip-adres en poort waar de verzendende machine naar luistert voor een binnenkomende verbinding. Vaak wordt ook de bestandsgrootte meegegeven:

DCC SEND <bestandsnaam> <ip> <poort> <bestandsgrootte> 

Volgens de oorspronkelijke standaard kon een ontvanger nu verbinden met het gegeven adres en poort en wachten op gegevens, of de aanvraag negeren. Voor clients die de DCC RESUME-uitbreiding ondersteunen, is het mogelijk om te vragen om een deel van het bestand over te slaan door het volgende CTCP antwoord te geven:

DCC RESUME <bestandsnaam> <poort> <positie> 

Als de zendende client DCC RESUME ondersteunt, zal hij antwoorden met

DCC ACCEPT <bestandsnaam> <poort> <positie> 

en kan de ontvanger met het gegeven adres en poort verbinden. Vervolgens zal hij alle binnenkomende data aan het bestaande bestand hangen.

Gegevens wordt in blokken gestuurd, en de client moet deze bevestigen door de grootte van de inkomende gegevensblokken als 32-bit network byte order integers terug te sturen. Dit vertraagt de verbinding, en is overbodig omdat verbindingscontrole al in TCP geïmplementeerd is. De Send-Ahead-uitbreiding lost dit probleem deels op door niet te wachten op de bevestigingen, maar omdat de ontvanger ze nog steeds moet verzenden voor elk ontvangen blok, in geval de ontvanger ze verwacht, is het probleem van overhead niet geheel opgelost. Een andere uitbreiding, TSEND of Turbo Send stuurt geen bevestigingen maar gebruikt een veranderde handshake (SEND wordt door TSEND vervangen) en is niet veel ondersteund.

De XMIT-dienst is een veranderde versie van DCC SEND die het hervatten van verbindingen ondersteunt en het verspillende bevestigen van blokken vermijdt. XMIT wordt niet wijd ondersteund.

De handshake van XMIT verschilt met de SEND-handshake. De zender biedt met een CTCP-commando een bestand aan aan de ontvanger:

DCC XMIT <protocol> <ip> <poort>[ <naam>[ <grootte> [<MIME-type>]]] 

waarbij blokhaken hier op optionele delen duidden. <protocol> is het protocol dat gebruikt wordt voor de overdracht, alleen "clear" is op het moment gedefinieerd. Anders dan bij standaard DCC SEND kan <ip> in de standaard dotted decimal-notatie voor IPv4 of in de hexadecimale of gemengde notatie van IPv6 zijn. Als een parameter leeg is maar een volgende meegegeven wordt, moet de eerste als "-" gegeven worden. Als de ontvanger het protocol niet ondersteunt, zendt hij een CTCP reply in het formaat:

ERRMSG DCC CHAT <protocol> unavailable 

CHAT wordt hier gebruikt om compatibiliteit met het extended extended DCC CHAT-Protocol te behouden. Als de gebruiker de verbinding weigert, zendt hij de volgende CTCP reply:

ERRMSG DCC CHAT <protocol> declined 

Andere berichten worden op vergelijkbare wijze verzonden. Als de ontvanger het bestand wil en kan ontvangen, zal het met het gegeven adres en poort verbinden. Wat dan gebeurt hangt af van het gebruikte protocol.

Als het "clear"-protocol gebruikt wordt, zal de XMIT-server, als hij een verbinding ontvangt, een 32-bit time_t in network byte order verzenden, wat de bewerkingstijd van het file geeft. Waarschijnlijk gebaseerd op de bewerkingstijd van het lokale bestand geeft een client vervolgens een network byte order long wat een startpunt geeft vanaf waar de server moet beginnen met verzenden. Dit startpunt is nul als de client het hele bestand wil en de grootte van het lokale bestand als de client een vorige download wil hervatten.

Hoewel het sneller is dan SEND, is het ook hier niet mogelijk om te weten hoe groot een bestand is, tenzij de bestandsgrootte gegeven wordt in de CTCP-onderhandeling. Ook is het niet mogelijk om een overdracht voorbij 2 gigabyte te hervatten dankzij het 32-byte startpunt.

Bij een normale DCC-verbinding is de initiator de server, de ontvanger is de client. Vanwege het gebruik van firewalls en NAT is het soms niet mogelijk voor de initiator om als server te dienen. Er zijn verschillende manieren bedacht om het doel te vragen als server op te treden.

Deze uitbreiding op normale DCC SEND en CHAT werd geïntroduceerd door IRC-client mIRC. DCC server is redelijk verspreid, maar niet op alle clients (zie Vergelijking van IRC-clients). Het doel en de initiater moeten het op de een of andere manier eens worden over een poort die ze kunnen gebruiken, waar het doel dan naar luistert. Een handshake vindt als volgt plaats:

Voor CHAT zendt de initiator:

100 <initiator nickname> 

Het doel antwoordt dan met:

110 <target nick> 

en vervolgens gaat het verder volgens het standaard DCC CHAT protocol.

Voor SEND zendt de initiator:

120 <initiator nickname> <bestandsgrootte> <bestandsnaam> 

Het doel antwoordt dan met:

121 <target nickame> <startpunt> 

waar <startpunt> het punt in het bestand is vanaf waar de verbinding hervat moet worden. Vervolgens gaat de verbinding verder als een normale DCC SEND.

DCC Server ondersteunt ook mIRC-achtige fileservers en DCC GET.

• SDCC
• XDCC

• (en) Een beschrijving van het DCC-protocol (verouderd, de meeste IRC-netwerken en IRC-clients hebben DCC uitgebreid)