Direct Client-to-Client ( DCC ) (originalmente Direct Client Connection [1] [2] [3] ) es un subprotocolo relacionado con IRC que permite a los pares interconectarse utilizando un servidor IRC para establecer contactos con el fin de intercambiar archivos o realizar tareas no relacionadas. -chats retransmitidos. Una vez establecida, una sesión DCC típica se ejecuta independientemente del servidor IRC. Originalmente diseñado para usarse con ircII , ahora es compatible con muchos clientes de IRC . Algunos clientes peer-to-peer en servidores con protocolo Napster también tienen capacidad de envío/obtención de DCC, incluidos TekNap, SunshineUN y Lopster. Una variación del protocolo DCC llamada SDCC (Secure Direct Client-to-Client), también conocida como DCC SCHAT, admite conexiones cifradas . No existe una especificación RFC sobre el uso de DCC.
Las conexiones DCC se pueden iniciar de dos maneras diferentes:
ircII fue el primer cliente IRC en implementar los protocolos CTCP y DCC. [4] El protocolo CTCP fue implementado por Michael Sandrof en 1990 para ircII versión 2.1. [5] El protocolo DCC fue implementado por Troy Rollo en 1991 para la versión 2.1.2, [6] pero nunca tuvo la intención de ser portátil a otros clientes de IRC. [7] [8]
El servicio CHAT permite a los usuarios chatear entre sí a través de una conexión DCC. [9] El tráfico irá directamente entre los usuarios y no a través de la red IRC. En comparación con el envío normal de mensajes, esto reduce la carga de la red IRC, permite enviar grandes cantidades de texto a la vez, debido a la falta de control de inundaciones, y hace que la comunicación sea más segura al no exponer el mensaje a los servidores IRC (sin embargo, el el mensaje todavía está en texto plano ).
DCC CHAT normalmente se inicia mediante un protocolo de enlace CTCP . El usuario que desea establecer la conexión envía el siguiente CTCP al destino, donde ip y puerto son la dirección IP y el número de puerto del remitente, y se expresan como números enteros. El protocolo es chat para DCC CHAT estándar. La parte receptora puede entonces conectarse al puerto y a la dirección IP indicados.DCC CHAT protocol ip port
Una vez que se establece una conexión, el protocolo utilizado para DCC CHAT es muy simple: los usuarios intercambian mensajes terminados en CRLF . Los mensajes que comienzan con un ASCII 001 (control-A, representado a continuación por [^A] ) y la palabra ACCIÓN , y terminan con otro ASCII 001 , se interpretan como gestos :.[^A]ACTION waves goodbye[^A]
Esta es una extensión de DCC CHAT, que permite enviar comandos de dibujo simples, así como líneas de texto. DCC Whiteboard se inicia con un protocolo de enlace similar al DCC CHAT, con el protocolo chat reemplazado por wboard : .DCC CHAT wboard ip port
Una vez establecida la conexión, los dos clientes intercambian mensajes terminados en CRLF . Los mensajes que comienzan (y opcionalmente terminan) con ASCII 001 se interpretan como comandos especiales; el comando ACCIÓN representa un gesto, mientras que otros hacen que se dibujen líneas en la superficie de la pizarra del usuario o permiten que los dos clientes negocien un conjunto de funciones.
El servicio ENVIAR permite a los usuarios enviarse archivos entre sí. La especificación original para el protocolo de enlace no permitía al receptor conocer el tamaño total del archivo ni reanudar una transferencia. Esto ha hecho que los clientes introduzcan sus propias extensiones para el protocolo de enlace, muchas de las cuales han recibido un amplio apoyo.
El protocolo de enlace original consistía en que el remitente enviara el siguiente CTCP al receptor: .DCC SEND filename ip port
Al igual que con DCC CHAT, ip y puerto son la dirección IP y el puerto donde la máquina emisora escuchará una conexión entrante. Algunos clientes incluyen nombres de archivos con espacios entre comillas dobles. Es una práctica común agregar el tamaño del archivo como último argumento: .DCC SEND filename ip port filesize
En este punto, la especificación original hacía que el receptor se conectara a la dirección y al puerto dados y esperara datos, o ignorara la solicitud, pero para los clientes que soportan la extensión DCC RESUME, una tercera alternativa es pedirle al remitente que omita parte del proceso. archivo enviando la respuesta CTCP: .DCC RESUME filename port position
Si el cliente emisor admite DCC RESUME, responderá con y el receptor podrá conectarse a la dirección y el puerto indicados y escuchar los datos para agregarlos a un archivo ya existente.DCC ACCEPT filename port position
Los datos se envían al cliente en bloques, cada uno de los cuales el cliente debe confirmar enviando el número total de bytes recibidos en forma de un entero de orden de bytes de red de 32 bits . Esto ralentiza las conexiones y es redundante debido a TCP . La extensión de envío anticipado alivia un poco este problema al no esperar los acuses de recibo, pero como el receptor aún tiene que enviarlos por cada bloque que recibe, en caso de que el remitente los espere, no se resuelve por completo.
Otra extensión, TDCC o turbo DCC, elimina los reconocimientos, pero requiere un protocolo de enlace ligeramente modificado y no cuenta con un soporte generalizado. Las versiones anteriores de TDCC reemplazaron la palabra ENVIAR en el protocolo de enlace por TSEND; Las versiones posteriores usan la palabra ENVIAR pero agregan una T después del protocolo de enlace, lo que hace que esta versión de TSEND sea compatible con otros clientes (siempre que puedan analizar el protocolo de enlace modificado).
El "exploit de envío DCC" puede referirse a dos errores: una variante de error de desbordamiento del búfer en mIRC desencadenado por nombres de archivos de más de 14 caracteres, [10] y un error de validación de entrada en algunos enrutadores fabricados por Netgear , D-Link y Linksys , desencadenado por el uso del puerto 0 . [11] [12] El exploit del enrutador, en particular, puede activarse cuando la frase ' DCC SEND ' seguida de al menos 6 caracteres sin espacios ni nuevas líneas aparece en cualquier lugar de una secuencia TCP en el puerto 6667, no solo cuando se realiza un DCC SEND real. se ha realizado la solicitud. En la década de 2000, era posible combinar múltiples exploits en una sola cadena, DCC SEND startkeylogger 0 0 0 , que si se publicaba en un canal público podía causar que varios usuarios se desconectaran (ya sea fallando clientes IRC, fallando enrutadores o activando valores predeterminados demasiado estrictos). configuración del software antivirus). [ cita necesaria ]
El servicio XMIT es una versión modificada de DCC SEND que permite reanudar archivos y reduce el tráfico innecesario de los ACK longs. XMIT no cuenta con un amplio soporte.
El protocolo de enlace XMIT difiere algo del protocolo de enlace SEND. El emisor envía un CTCP ofreciendo un fichero al receptor:DCC XMIT protocol ip port[ name[ size[ MIME-type]]]
Los corchetes aquí encierran piezas opcionales. protocolo es el protocolo a utilizar para la transferencia; sólo claro está definido actualmente. A diferencia del estándar DCC SEND, ip puede estar en las formas adicionales de notación de puntos estándar para IPv4, o en notación hexadecimal o mixta para IPv6. Para dejar vacío un parámetro inicial, pero aún así proporcionar uno posterior, el anterior se puede especificar como - . Si el receptor no implementa el protocolo utilizado, enviará una respuesta CTCP con el formato: .ERRMSG DCC CHAT protocol unavailable
CHAT se utiliza aquí para mantener la compatibilidad con los mensajes de error enviados por el CHAT DCC extendido. Si el receptor rechaza la transferencia, envía la siguiente respuesta CTCP: .ERRMSG DCC CHAT protocol declined
Otros errores se informan de la misma manera. Si el receptor está dispuesto y es capaz de recibir el archivo, se conectará a la dirección y al puerto indicados. Lo que suceda entonces depende del protocolo utilizado.
En el caso del protocolo claro , el servidor XMIT, al recibir una conexión, enviará un orden de bytes de red de 32 bits , que representa el tiempo de modificación del archivo. Presumiblemente, basándose en la hora de modificación del archivo local, el cliente enviará otro orden de bytes de red , un desplazamiento que el servidor debe buscar al enviar el archivo. Esto debe establecerse en cero si se desea el archivo completo, o el tamaño del archivo local si el cliente desea reanudar una descarga anterior.time tlong
Si bien es más rápido que SEND, XMIT tiene las mismas limitaciones: es imposible saber qué tan grande es el archivo, a menos que su tamaño se especifique en la negociación CTCP o se conozca de antemano. Además, no es posible reanudar un archivo que supere la marca de dos gigabytes debido al desplazamiento de 32 bits.
En una conexión DCC normal, el iniciador actúa como servidor y el destino es el cliente . Debido al firewall generalizado y a la reducción de la transparencia de un extremo a otro debido a NAT , es posible que el iniciador no pueda actuar como servidor. Se han ideado varias formas de pedirle al objetivo que actúe como servidor:
Esta extensión para DCC SEND y CHAT normal fue introducida por el cliente IRC mIRC . DCC Server tiene soporte moderado, pero no es estándar en todos los clientes (consulte Comparación de clientes de Internet Relay Chat ).
Permite el inicio de una conexión DCC por dirección IP, sin necesidad de un servidor IRC. Esto se logra cuando el cliente receptor actúa como servidor (de ahí el nombre) escuchando (generalmente en el puerto 59) un apretón de manos del remitente.
Para un CHAT, el iniciador envía . Luego, el objetivo responde con, y el resto procede de acuerdo con el protocolo estándar DCC CHAT.1000 initiator nick1000 target nick
Para un ENVÍO, el iniciador envía . El objetivo responde con, , donde la posición de reanudación es el desplazamiento en el archivo desde el cual comenzar. A partir de aquí la transferencia se realiza como un ENVÍO DCC normal.1200 initiator nick filesize filename1210 target nick resume position
DCC Server también admite servidores de archivos estilo mIRC y DCC GET.
El servidor DCC no proporciona ninguna forma de especificar el puerto a utilizar, por lo que esto debe negociarse manualmente, lo que no siempre es posible, ya que una de las partes puede no ser un humano. RDCC es un mecanismo de protocolo de enlace para el servidor DCC, que además del puerto también proporciona la dirección IP del servidor, que de otro modo el cliente podría no poder encontrar debido al enmascaramiento del host. No cuenta con un amplio apoyo.
El iniciador solicita el puerto en el que está escuchando el objetivo enviando la consulta CTCP, donde la función es c para chat, s para enviar o f para servidor de archivos.RDCC function comment
El objetivo puede entonces responder CTCP con, , donde ip y puerto tienen los mismos significados que para DCC SEND y CHAT normales. Después de esto, el iniciador se conecta a la IP y al puerto , y sigue un protocolo de enlace del servidor DCC.RDCC 0 ip port
A diferencia del servidor DCC, donde el protocolo de enlace se maneja a través de una conexión IP directa, DCC REVERSE tiene un protocolo de enlace CTCP normal, similar al utilizado por DCC SEND. Esto no se implementa ampliamente. El remitente ofrece un archivo al receptor enviando el mensaje CTCP: . La clave es una cadena de caracteres ASCII de 1 a 50 caracteres de longitud en el rango de 33 a 126 y actúa como un identificador para la transferencia.DCC REVERSE filename filesize key
Si el receptor acepta, envía la respuesta CTCP,DCC REVERSE key start ip port
Aquí, inicio es la posición en el archivo desde la cual comenzar a enviar, ip es la dirección IP del receptor en notación de puntos estándar para IPv4 o notación hexadecimal para IPv6 . Luego, el remitente se conecta a la dirección IP y al puerto indicados por el receptor, y sigue un ENVÍO DCC normal. Tanto el remitente como el receptor pueden cancelar el protocolo de enlace enviando la respuesta CTCP .DCC REJECT REVERSE key
Esta es la alternativa del cliente KVIrc a DCC REVERSE. El remitente ofrece un archivo enviando el CTCP: . Luego, el receptor puede aceptar mediante CTCP respondiendo con, y el remitente se conecta al receptor y envía como durante un ENVÍO DCC normal.DCC RSEND filename filesizeDCC RECV filename ip port start
Este mecanismo DCC pasivo es compatible al menos con mIRC , Visual IRC , HexChat , KVIrc, DMDirc , Klient, Konversation y PhibianIRC. El remitente ofrece un archivo enviando el mensaje CTCP, . ip es la dirección IP del remitente en orden de bytes de red, expresada como un entero único (como en DCC estándar). Se envía el número 0 en lugar de un puerto válido, lo que indica que se trata de una solicitud DCC inversa. el token es un número entero único; Si se utiliza TSEND (por un cliente que lo admite), se agrega la letra T al token, lo que le permite al receptor saber que no necesita enviar acuses de recibo.DCC SEND filename ip 0 filesize token
El receptor puede aceptar el archivo abriendo un conector de escucha y respondiendo con el mensaje CTCP, . Esto es idéntico al mensaje DCC inverso original, excepto que la IP y el puerto identifican el conector donde el receptor está escuchando. El token es el mismo que en la solicitud original, lo que le permite al remitente saber qué solicitud se acepta. (Debido a que este mensaje sigue el mismo formato que una solicitud de envío DCC normal, algunos servidores que filtran solicitudes DCC pueden requerir que el remitente agregue el receptor a su lista de "permitidos DCC").DCC SEND filename ip port filesize token
Luego, el remitente se conecta al socket del receptor, envía el contenido del archivo y espera a que el receptor cierre el socket cuando finalice el archivo.
Cuando se utiliza la extensión RESUME del protocolo SEND, la secuencia de comandos se convierte en (donde >> indica un mensaje saliente en el lado iniciador y << respuesta de su par):
>> 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 (es decir, el remitente se conecta al conector del receptor).
Un servidor DCC , o servidor de archivos, permite al usuario explorar, leer y descargar archivos ubicados en un servidor DCC.
Normalmente, esto se implementa con una sesión DCC CHAT (que presenta al usuario un símbolo del sistema) o comandos CTCP especiales para solicitar un archivo. Los archivos se envían a través de DCC SEND o DCC XMIT. Existen muchas implementaciones de servidores de archivos DCC, entre ellas se encuentra el comando FSERV en el popular cliente mIRC .
Los autores del paquete de software ircII fueron originalmente pioneros en la transferencia de archivos a través de IRC.
El primer comentario que debo hacer es que el protocolo DCC nunca fue diseñado para ser portátil a clientes distintos del IRCII.
Como tal, no me hago responsable de que sea difícil de implementar para otros clientes.