Cliente-a-Cliente Directo

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada. Busca fuentes: «Cliente-a-Cliente Directo» – noticias · libros · académico · imágenes Este aviso fue puesto el 9 de mayo de 2012.

El Cliente-a-Cliente Directo, del inglés Direct Client-to-Client (DCC), es un protocolo de Internet Relay Chat (IRC) que permite interconectar dos peers o puntos usando un servidor IRC como saludo (handshaking) para permitir intercambiar archivos o llevar a cabo tareas no relacionadas con el chat. Una vez conectados, una típica sesión de DCC corre independiente del servidor IRC.

Originalmente diseñado para ser usado con ircII, es ahora soportado por varios clientes IRC.

La conexión DCC puede ser iniciada de dos formas diferentes:

1. la forma más común es usando CTCP para iniciar una sesión DCC.
   • El CTCP es enviado de un usuario sobre la red IRC hacia otro usuario.
2. Otra forma es iniciar una sesión DCC en el cliente para conectarse directamente al servidor DCC.
   • Usando este método, no necesita atravesar una red IRC (las partes involucradas no necesitan estar conectadas a una red IRC para usar DCC).^[1]​

El servicio de chat permite a los usuarios charlar el uno con el otro en una conexión DCC. El tráfico va directamente entre usuarios y no sobre la red IRC. Cuando lo comparamos con el envío normal de mensajes, este reduce la carga en la red IRC. Permitiendo el envío de una gran cantidad de texto de una vez, evitando retrasos, saturación, haciendo la comunicación más segura no exponiendo el mensaje a los servidores de IRC (el mensaje sigue siendo texto plano).

El chat DCC es normalmente iniciado usando un saludo CTCP. El usuario que desea establecer la conexión envía el siguiente CTCP al destino:

DCC Chat <protocolo><ip><puerto>

Donde:

• <ip> y <puerto> son los del origen y están expresado con números enteros (integer).
• <protocolo> es "CHAT" en el estándar DCC CHAT. El que recibe puede entonces conectase con el puerto y la dirección recibidos.

Una vez que la conexión es establecida, el protocolo usado para el chat DCC es muy simple: los usuarios intercambian mensajes terminados en CRLF. Mensajes que comienzan con un ASCII 001 (Control+A, representado por "^A") y la palabra "ACTION" y están opcionalmente terminados por otro ASCII 001, que será interpretado como un emotivo:

^AACTION waves goodbye^A

Esta una extensión de DCC Chat, que permite comandos para dibujar y ser enviados como líneas de texto. DCC Whiteboard es inicializado con un saludo (handshake) similar al del DCC Chat, con el pseudo nombre de archivo “Chat” reemplazado por “wboard”:

DCC CHAT wboard <ip><port>

Una vez que la conexión es establecida, los dos clientes intercambian mensajes terminados con CRLF. Los mensajes que comienzan (y opcionalmente terminan) ASCII 001 son interpretados como comando especiales, el comando ACTION representa una emoción, mientras otros hacen que sean dibujadas líneas en la pizarra del usuario (whiteboard), o permite que dos clientes negocien un conjunto de sus características.

El servicio de envío (send) permite a los usuarios enviarse archivo entre ellos. La especificación original para el saludo (handshake) no permitía al receptor conocer el tamaño total del archivo, pausar y reanudar (resume) la transferencia. Esto hizo que los clientes introdujeran sus propias extensiones para el saludo (handshake), muchas de las cuales lograron un amplio soporte.

El saludo original consistía que el emisor enviaba el siguiente CTCP al destinatario:

DCC SEND <filename><ip><port>

Como en el DCC Chat:

• <ip> y <port> son la dirección IP y el puerto de la máquina emisora donde escuchará la conversación entrante. Esta es una práctica común, el agregar el tamaño del archivo como último argumento.

DCC SEND <filename><ip><port><file size>

En este punto, la especificación original tenía al receptor conectado a la dirección dada y el puerto esperando los datos, o ignorar el pedido, pero para clientes que soportan la extensión DCC RESUME, una tercera alternativa es preguntar al remitente saltarse una parte del archivo enviando un CTCP reply:

DCC RESUME <filename><port><position>

Si el cliente soporta DCC RESUME, este responderá con un:

DCC ACCEPT <filename><port><position>

Y el receptor puede conectarse a la dirección y al puerto dato y escuchar los datos para añadirlo en el archivo.

Los datos se envían en bloques, a los que el cliente debe corresponder enviando los tamaños de los bloques de datos entrantes como enteros de 32 bits (Endianness, network byte order). Esto ralentiza las conexiones, y es redundante porque tal comportamiento ya está implementado por Transmission Control Protocol (TCP). La extensión send-ahead solventa este problema no esperando las respuestas, pero ya que el receptor aún debe enviarlas por cada bloque que recibe, en el caso de que el emisor las espere, no está completamente solucionado.

Otra extensión, TDCC, o turbo DCC, elimina las respuestas, pero requiere un saludo (handshake) ligeramente modificado y no está ampliamente soportado. Versiones más antiguas de TDCC reemplazan la palabra SEND en el saludo con TSEND; versiones posteriores usan la palabra SEND pero añaden "T" después del saludo, haciendo esta versión de TSEND compatible con otros clientes (tanto como estos puedan analizar el saludo modificado).

El servicio XMIT es una versión modificada de DCC SEND que permite reanudar archivos y cortes. XMIT no está ampliamente soportado.

El saludo XMIT difiere algo del saludo SEND. El emisor envía un CTCP ofreciendo un archivo al receptor:

DCC XMIT <protocol> <ip> <port>[ <name>[ <size> [<MIME-type>]]]

• Los corchetes aquí encierran las partes opcionales.
• <protocol> es el protocolo a usar para la transferencia; sólo "clear" se define en este momento. Al contrario que en DCC SEND estándar, la <ip> puede estar en formas adicionales de la notación estándar para IPv4, o en hexadecimal o en notación mixta para IPv6. Para dejar un parámetro vacío y especificarlo posteriormente, dicho parámetro podrá especificarse como "-". Si el receptor no implementa el protocolo utilizado, responderá con un CTCP reply en el formato:

ERRMSG DCC CHAT <protocol> unavailable

El CHAT se usa aquí para mantener la compatibilidad con los mensajes de error enviados por DCC CHAT extendido. Si el receptor declina la transferencia, envía el siguiente CTCP reply:

ERRMSG DCC CHAT <protocol> declined

Otros errores son reportados de la misma manera. Si el receptor está dispuesto y capaz de recibir el archivo, conectará a la dirección y puerto dados. Lo que pase después dependerá del protocolo usado.

En el caso del protocolo "clear", el servidor XMIT, para recibir una conexión, enviará un valor de tiempo time t de 32 bits en (network byte order), representando el tiempo de modificación del archivo. En principio, basándose en el tiempo de modificación del archivo local, el cliente entonces enviará otro dato de tipo long en (network byte order), un offset que el servidor debería buscar cuando envía el archivo. Este debería ser cero si se quiere todo el archivo, o el tamaño del archivo local si el cliente desea reanudar una descarga previa.

Aunque es más rápido que SEND, XMIT lleva una de las mismas limitaciones en la que es imposible indicar el tamaño del archivo, a no ser que su tamaño sea especificado en el CTCP de la negociación o conocido antes del saludo. Además, no puedes reanudar un archivo pasada la marca de los dos gigabytes debido al offset de 32 bites.

En una conexión DCC normal, el iniciador actúa como servidor, y el destino es el cliente. A causa del extendido cortafuegos y la reducción de transparencia de punto-a-punto debido al Network Address Translation (NAT), el iniciador podría no ser capaz de actuar como un servidor. Se han inventado varias formas de solicitar al destino que actúe como el servidor:

Esta extensión al DCC SEND y CHAT normales fue introducido por el cliente de IRC denominado mIRC. El servidor DCC tiene soporte moderado, pero no es un estándar en todos los clientes.

Permite la iniciación de una conexión DCC por dirección IP, sin la necesidad de un servidor IRC. Eso se lleva a cabo recibiendo al cliente que actúa como un servidor (de ahí el nombre) a la espera (normalmente a través del puerto 59) de un saludo por parte del emisor.

Para un CHAT, el iniciador envía:

100 <initiator nick>

El destino entonces responde con:

101 <target nick>

El resto procede de acuerdo con el protocolo estándar del DCC CHAT.

Para un SEND, el iniciador envía:

120 <initiator nick> <filesize> <filename>

El destino responde con:

121 <target nick> <resume position>

Donde <resume position> es el offset del archivo en el cual empezar. Desde aquí la transferencia procede como un DCC SEND normal.

El servidor DCC también soporta servidores de archivos estilo-mIRC y DCC GET.

El servidor DCC no proporciona forma alguna de especificar el puerto a utilizar, así que esto ha de negociarse manualmente, lo cual no siempre es posible, ya que una de las partes puede no ser humana. RDCC es un mecanismo de saludo (handshake) para servidor DCC, en el que además del puerto proporciona la dirección IP del servidor, que de otra manera el cliente podría no ser capaz de encontrar debido al enmascaramiento del host. No está ampliamente soportado.

El iniciador solicita el puerto en el que el destino escucha, enviando la petición CTCP:

RDCC <function> <comment>

Donde <function> es c para chat, s para enviar y f para servidor de archivos. El destino puede entonces responder con un CTCP:

RDCC 0 <ip> <port>

Donde <ip> y <port> tienen el mismo significado que para un DCC SEND y CHAT normales. Después, el iniciador conecta a la IP y puerto y el saludo DCC Server prosigue.

Al contrario que con DCC Server, donde el saludo se maneja directamente sobre la conexión IP, DCC REVERSE tiene un saludo CTCP normal, similar al utilizado por DCC SEND. Esto no está ampliamente soportado. El emisor ofrece un archivo al receptor enviando el mensaje CTCP:

DCC REVERSE <filename> <filesize> <key>

Donde <key> es una cadena de 1 a 50 caracteres de longitud formado por caracteres ASCII de rango 33 a 126, y actúa como un identificador para la transferencia. Si el receptor acepta, envía la respuesta CTPC:

DCC REVERSE <key> <start> <ip> <port>

Aquí <start> es la posición del archivo en la que empezará el envío, <ip> es la dirección IP del receptor en notación estándar para IPv4, o notación hexadecimal para IPv6. Luego, el emisor conecta a la dirección IP y puerto indicados por el receptor, y le sigue un DCC SEND normal. Tanto el emisor como el receptor pueden cancelar el saludo enviando la respuesta CTPC:

DCC REJECT REVERSE <key>

Esta es la alternativa del cliente KVIrc a DCC REVERSE. El emisor ofrece un archivo enviando el CTCP.

DCC RSEND <filename> <filesize>

El receptor puede aceptar respondiendo con un CTCP.

DCC RECV <filename> <ip> <port> <start>

Y el emisor conecta al receptor y transmite como en un DCC SEND normal.

Este mecanismo de DCC pasivo está soportado al menos por mIRC, Visual IRC, XChat, HexChat y KVIrc. El emisor ofrece un archivo enviando el mensaje CTCP:

DCC SEND <filename> <ip> 0 <filesize> <token>

Donde <ip> es la dirección IP del emisor en (network byte order), expresado como un simple entero (como en DCC estándar). El número 0 se envía en vez de un puerto válido, indicando que esto es una petición de DCC inverso. El <token> es un entero único; si está siendo usado TSEND (por un cliente que lo soporta), la letra "T" se añadirá al token, permitiendo al receptor saber que no necesita enviar respuestas por cada bloque recibido.

El receptor puede aceptar el archivo abriendo un socket de escucha y respondiendo con el mensaje CTCP:

DCC SEND <filename> <ip> <port> <filesize> <token>

Esto es idéntico al mensaje original del DCC inverso, excepto que la <ip> y <port> identifican el socket donde el receptor está escuchando. El <token> es el mismo que en la petición original, permitiendo al emisor saber qué petición está siendo aceptada. (Desde que este mensaje sigue el mismo formato que una petición DCC Send regular, algunos servidores con filtro de peticiones DCC pueden requerir que el emisor añada al receptor en su lista de "DCC permitidos").

El emisor entonces conecta al socket del receptor, envía el contenido del archivo, y espera a que el receptor cierre el socket cuando el archivo esté finalizado.

Cuando se usa la extensión RESUME al protocolo SEND, la secuencia de comandos llega a ser (con >> indicando un mensaje saliente en el lado iniciador y << respondido por su peer):

>> DCC SEND <filename> <ip> 0 <filesize> <token>
<< DCC RESUME <filename> 0 <position> <token>
>> DCC ACCEPT <filename> 0 <position> <token>
<< DCC SEND <filename> <peer-ip> <port> <filesize> <token>

Después de lo cual, el protocolo continúa normalmente (por ejemplo el emisor conecta al socket del receptor).

Un DCC fserve, o servidor de archivo, permite a un usuario navegar, leer y descargar archivos localizados en un servidor DCC.

Normalmente, esto se implementa en una sesión DCC CHAT (la cual se presenta al usuario con un comando prompt) o comandos CTCP especiales para solicitar un archivo. Los archivos se envían sobre DCC SEND o DCC XMIT. Hay muchas implementaciones de servidores de archivo DCC. Entre ellos está el comando FSERV en el popular cliente mIRC.

SDCC (Secure Direct Client-to-Client), también conocido como DCC SCHAT, es una variación del protocolo DCC que permite a dos individuos mantener una charla privada en IRC con cifrado sin que se produzca un lag.

Este no es muy usado.

• XDCC

• Descripción del protocolo DCC (en inglés) (nota: La mayoría de los clientes de IRC y redes han implementado extensiones al protocolo DCC. El DCC comúnmente utilizado hoy ha cambiado un poco desde lo que este documento describe. Se está formalizando un sucesor del DCC (DCC2) por DCC2.org)
• DCC negociación y conexión (en inglés)
• Descripción del protocolo Turbo DCC (en inglés)
• Descripción del protocolo DCC Whiteboard (en inglés)