El protocolo de cliente a cliente ( CTCP ) es un tipo especial de comunicación entre clientes de Internet Relay Chat (IRC).
CTCP es un protocolo común implementado por la mayoría de los principales clientes de IRC en uso hoy en día. [ cita requerida ] CTCP extiende el protocolo IRC original al permitir que los usuarios consulten a otros clientes o canales, esto hace que todos los clientes en el canal respondan al CTCP, para obtener información específica. Además, CTCP se puede utilizar para codificar mensajes que el protocolo IRC sin formato no permitiría enviar a través del enlace, como mensajes que contienen nuevas líneas o el valor de byte 0 (NULL). CTCP no establece una conexión directa entre clientes; sin embargo, se utiliza comúnmente para negociar conexiones DCC .
CTCP permite a los usuarios consultar a un cliente remoto sobre la versión del cliente que están utilizando (a través de CTCP VERSION), o la hora (a través de CTCP TIME), entre otras cosas. También se utiliza para implementar el comando /me (a través de CTCP ACTION).
ircII fue el primer cliente de IRC en implementar los protocolos CTCP y DCC. [1] El protocolo CTCP fue implementado por Michael Sandrof en 1990 para la versión 2.1 de ircII, [2] mientras que el protocolo DCC fue implementado por Troy Rollo en 1991 para la versión 2.1.2. [3]
Un mensaje CTCP se implementa como un PRIVMSGo NOTICEdonde el primer y el último carácter del mensaje son valores ASCII 0x01. Además, se escapan los caracteres que no estarían permitidos en el protocolo IRC. Dado que un NOTICEcomo estándar no debería generar una respuesta, los mensajes CTCP se envían como PRIVMSGy la respuesta se implementa con un NOTICEen lugar de un PRIVMSG.
Una consulta CTCP se inicia en la mayoría de los clientes de la siguiente manera:
CTCP <objetivo> <comando> <argumentos>
Donde <target> es el apodo o canal del objetivo, <command> es el comando CTCP (por ejemplo VERSION, ) y <arguments> es información adicional que se enviará a <target> .
Los comandos y respuestas CTCP son específicos del cliente; por lo tanto, dependiendo del cliente IRC, algunos de los siguientes comandos CTCP pueden no generar una respuesta o tener un formato diferente al que se muestra aquí.
Una CTCP VERSIONsolicitud devolverá el nombre y la versión del cliente IRC que utiliza el objetivo y, en algunos casos, información técnica como el sistema operativo , la frecuencia de reloj , el fabricante de la CPU y la arquitectura de la CPU / conjunto de instrucciones .
Un ejemplo de respuesta para una CTCP VERSIONsolicitud a un destino que utiliza el cliente HexChat es:
VERSIÓN HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]
Una CTCP TIMEsolicitud devolverá la hora local del equipo de destino. Según el cliente IRC, la respuesta puede consistir en la fecha , la hora (en formato de 12 horas o de 24 horas ), el año (por ejemplo, 2012) y, a veces, la zona horaria (por ejemplo, EST ).
Un ejemplo de respuesta para una CTCP TIMEsolicitud a un destino que utiliza el cliente ChatZilla es:
HORA Viernes 23 de noviembre de 2012 19:26:42 EST
Una CTCP PINGsolicitud determinará la tasa de ping que existe directamente entre dos clientes (es decir, descontando el servidor). El CTCP PINGcomando funciona enviando un argumento (a menudo) entero (una marca de tiempo ) a un cliente de destino, el cliente de destino responde suministrando exactamente el mismo parámetro numérico. Se calcula la diferencia entre la marca de tiempo original y la marca de tiempo actual, y el resultado se muestra al usuario que inició el CTCP PING . La mayoría de las veces, se utiliza una marca de tiempo que utiliza milisegundos debido a que la mayoría de los usuarios con conexiones a Internet de banda ancha tienen un ping inferior a 1 segundo.
Un ejemplo de CTCP PINGsolicitud para dirigirse a <nickname> desde el cliente XChat es:
PING CTCP23152511
De la misma manera, el resultado de muestra generado a partir de la diferencia (ver arriba) es:
Respuesta de ping de <nickname>: 0,53 segundos
El servicio CHAT permite a los usuarios chatear entre sí a través de una conexión DCC. [4] El tráfico se dirigirá 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 mensaje sigue siendo texto simple ).
El 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 port 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 el DCC CHAT estándar. La parte receptora puede entonces conectarse al puerto y la dirección IP indicados.DCC CHAT protocol ip port
Una vez establecida la conexión, el protocolo utilizado para DCC CHAT es muy simple: los usuarios intercambian mensajes con terminación CRLF . Los mensajes que comienzan con un ASCII 001 (control-A, representado a continuación por [^A] ) y la palabra ACTION , y terminan con otro ASCII 001 , se interpretan como emoticones: .[^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 a 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 con terminación CRLF . Los mensajes que comienzan (y opcionalmente terminan) con ASCII 001 se interpretan como comandos especiales; el comando ACTION 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 características.
El servicio SEND permite a los usuarios enviarse archivos entre sí. La especificación original del protocolo de enlace no permitía al receptor conocer el tamaño total del archivo ni reanudar una transferencia. Esto ha obligado a los clientes a introducir sus propias extensiones para el protocolo de enlace, muchas de las cuales han pasado a tener un amplio soporte.
El protocolo de enlace original consistía en que el remitente enviaba el siguiente CTCP al receptor: .DCC SEND filename ip port
Al igual que con DCC CHAT, ip y port son la dirección IP y el puerto donde la máquina emisora escuchará una conexión entrante. Algunos clientes encierran los nombres de archivo 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 puerto indicados y esperara los datos, o ignorara la solicitud, pero para los clientes que admiten la extensión DCC RESUME, una tercera alternativa es pedirle al remitente que omita parte del archivo enviando la respuesta CTCP: .DCC RESUME filename port position
Si el cliente remitente admite DCC RESUME, responderá con, y el receptor podrá conectarse a la dirección y puerto indicados y escuchar 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 reconocer 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 send-ahead alivia este problema en cierta medida al no esperar los reconocimientos, pero como el receptor aún tiene que enviarlos para 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 tiene una amplia compatibilidad. Las versiones anteriores de TDCC reemplazaron la palabra SEND en el protocolo de enlace por TSEND; las versiones posteriores usan la palabra SEND 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: un error de desbordamiento de búfer variante en mIRC activado por nombres de archivo de más de 14 caracteres, [5] y un error de validación de entrada en algunos enrutadores fabricados por Netgear , D-Link y Linksys , activado por el uso del puerto 0. [ 6] [7] 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 un flujo TCP en el puerto 6667, no solo cuando se ha realizado una solicitud DCC SEND real. 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 provocar que varios usuarios se desconectaran (ya sea bloqueando clientes IRC, bloqueando enrutadores o activando configuraciones predeterminadas demasiado estrictas en el software antivirus). [ cita requerida ]
El servicio XMIT es una versión modificada de DCC SEND que permite reanudar archivos y reduce el tráfico innecesario de los mensajes ACK long. XMIT no tiene una amplia compatibilidad.
El protocolo de enlace XMIT difiere un poco del protocolo de enlace SEND. El remitente envía un CTCP que ofrece un archivo al receptor:DCC XMIT protocol ip port[ name[ size[ MIME-type]]]
Los corchetes encierran aquí partes opcionales. protocol es el protocolo que se utilizará para la transferencia; actualmente solo se define clear . A diferencia del DCC SEND estándar, ip puede estar en las formas adicionales de notación estándar con puntos para IPv4, o en notación hexadecimal o mixta para IPv6. Para dejar un parámetro temprano vacío, 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
Aquí se utiliza CHAT para mantener la compatibilidad con los mensajes de error enviados por el DCC CHAT 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 sucede a continuación depende del protocolo utilizado.
En el caso del protocolo clear , el servidor XMIT, al recibir una conexión, enviará un byte order de 32 bits en red , que representa la hora de modificación del archivo. Presumiblemente, basándose en la hora de modificación del archivo local, el cliente enviará otro byte order de red , un desplazamiento que el servidor debe buscar al enviar el archivo. Este debe establecerse en cero si se desea el archivo completo, o en 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 una de las mismas limitaciones, ya que es imposible determinar el tamaño del 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 más allá de la marca de los dos gigabytes debido al desplazamiento de 32 bits.
En una conexión DCC normal, el iniciador actúa como servidor y el objetivo es el cliente . Debido a la utilización generalizada de cortafuegos y a la reducción de la transparencia de extremo a extremo 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 de los servicios DCC SEND y CHAT normales fue introducida por el cliente IRC mIRC . El servidor DCC tiene un soporte moderado, pero no es estándar en todos los clientes (consulte Comparación de clientes de Internet Relay Chat ).
Permite iniciar una conexión DCC por dirección IP, sin necesidad de un servidor IRC. Esto se logra cuando el cliente receptor actúa como un servidor (de ahí el nombre) que escucha (normalmente en el puerto 59) un protocolo de enlace del remitente.
En el caso de un CHAT, el iniciador envía . El destinatario responde con , y el resto continúa según el protocolo estándar DCC CHAT.1000 initiator nick1000 target nick
Para un SEND, el iniciador envía . El destino responde con , donde la posición de reanudación es el desplazamiento en el archivo desde el cual se debe comenzar. A partir de aquí, la transferencia continúa como un SEND DCC normal.1200 initiator nick filesize filename1210 target nick resume position
El servidor DCC también admite servidores de archivos de estilo mIRC y DCC GET.
El servidor DCC no ofrece ninguna forma de especificar el puerto que se debe utilizar, por lo que debe negociarse manualmente, lo que no siempre es posible, ya que una de las partes puede no ser una persona. RDCC es un mecanismo de enlace para el servidor DCC que, además del puerto, también proporciona la dirección IP del servidor, que el cliente podría no encontrar de otra manera debido al enmascaramiento del host. No se admite ampliamente.
El iniciador solicita el puerto en el que está escuchando el destino 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 se produce un protocolo de enlace del servidor DCC.RDCC 0 ip port
A diferencia de DCC Server, donde el protocolo de enlace se gestiona a través de una conexión IP directa, DCC REVERSE tiene un protocolo de enlace CTCP normal, similar al que utiliza DCC SEND. Esto no se ha implementado ampliamente. El remitente ofrece un archivo al receptor enviando el mensaje CTCP: . key es una cadena de caracteres ASCII de entre 1 y 50 caracteres en el rango 33-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í, start es la posición en el archivo desde la que se inicia el envío, ip es la dirección IP del receptor en notación estándar con puntos para IPv4 o notación hexadecimal para IPv6 . A continuación, el remitente se conecta a la dirección IP y al puerto indicados por el receptor y se realiza un envío DCC SEND 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: . El receptor puede aceptarlo respondiendo con CTCP, y el remitente se conecta al receptor y envía como durante un DCC SEND normal.DCC RSEND filename filesizeDCC RECV filename ip port start
Este mecanismo DCC pasivo es compatible con al menos 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 solo entero (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. token es un entero único; si se utiliza TSEND (por un cliente que lo admite), se agrega la letra T al token, lo que permite que el receptor sepa que no necesita enviar reconocimientos.DCC SEND filename ip 0 filesize token
El receptor puede aceptar el archivo abriendo un socket de escucha y respondiendo con el mensaje CTCP. Este mensaje es idéntico al mensaje DCC inverso original, excepto que la dirección IP y el puerto identifican el socket en el que el receptor está escuchando. El token es el mismo que en la solicitud original, lo que permite que el remitente sepa qué solicitud se está aceptando. (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 al receptor a su lista de "permisos 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 el archivo termina.
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 de manera normal (es decir, el remitente se conecta al socket del receptor).
Un servidor de archivos o fserve DCC permite a un usuario explorar, leer y descargar archivos ubicados en un servidor DCC.
Por lo general, esto se implementa con una sesión DCC CHAT (que presenta al usuario un mensaje de solicitud de comando) 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.