Internet Relay Chat
De Wikipedia, la enciclopedia libre
  (Redirigido desde el operador del canal de Internet Relay Chat )
Saltar a navegación Saltar a búsqueda
"IRC" vuelve a dirigir aquí. Para otros usos, consulte IRC (desambiguación) . Para los canales de IRC relacionados con Wikipedia, consulte Wikipedia: IRC .
Conjunto de protocolos de internet
Capa de aplicación
Capa de transporte
Capa de internet
Capa de enlace
  • ARP
  • NDP
  • OSPF
  • Túneles
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Wifi
    • DSL
    • RDSI
    • FDDI
  • más...
  • v
  • t
  • mi
El primer servidor IRC, tolsun.oulu.fi, un servidor Sun-3 en exhibición cerca del centro de computación de la Universidad de Oulu . (2001)

Internet Relay Chat (IRC) es un sistema de chat basado en texto. Permite discusiones entre cualquier número de participantes en los llamados canales de conversación, así como discusiones entre solo dos socios, por ejemplo, en diálogos de preguntas y respuestas. [1] Cualquier participante puede abrir un nuevo canal de conversación, y un solo usuario de computadora también puede participar en varios de estos canales simultáneos.

Para establecer o unirse a un chat, se requiere un programa de red, llamado cliente IRC, para acceder a un canal mediante la conexión a un servidor. El cliente de IRC puede ser un programa independiente en la computadora local (por ejemplo, mIRC, XChat) o tomar la forma de una interfaz de usuario especial dentro de un programa más grande, como un navegador de Internet; el navegador Opera , por ejemplo, incluye un cliente IRC, y clientes como Mibbit e IRCCloud o el código abierto KiwiIRC y The Lounge Chat del MIT pueden funcionar en conexión con muchos navegadores populares.

Se utiliza una red IRC de servidores interconectados que funcionan como estaciones repetidoras para mediar en las llamadas en el IRC. La característica esencial de esta red es su topología de comunicación BITNET, que permite solo una ruta de comunicación entre dos participantes. Históricamente, esto aseguraba una comunicación eficiente, porque en los primeros días del IRC, las líneas de datos intercontinentales tenían una capacidad muy limitada. La topología permitió que un mensaje de un cliente en un continente no se enviara individualmente para cada cliente en otro continente, sino solo una vez a un servidor local, que luego lo distribuyó a los clientes. A pesar de las capacidades de gestión limitadas, eran posibles "paisajes de charla" muy grandes. La desventaja es la falta de redundancia, que se manifiesta en las llamadas divisiones de red: si falla algún servidor,la red se divide automáticamente en partes separadas hasta que se establece una nueva conexión entre las partes.

Las redes de IRC más grandes consisten en varias docenas de servidores de IRC que conectan simultáneamente a más de 100,000 usuarios y administran decenas de miles de canales, en cada uno de los cuales varios miles de personas pueden participar simultáneamente. A pesar de estas enormes proporciones, el retraso en un texto enviado suele ser del orden de décimas de segundo y rara vez supera el tiempo de un segundo.

El uso de IRC ha ido disminuyendo de manera constante desde 2003, perdiendo el 60 por ciento de sus usuarios (de 1 millón a aproximadamente 400,000 en 2021) y la mitad de sus canales (de medio millón en 2003 a menos de 200,000 en 2021). [2] En abril de 2011, las 100 principales redes de IRC atendían a más de medio millón de usuarios a la vez, [3] alojaban cientos de miles de canales [3] que operaban en un total de aproximadamente 1 500 servidores [3] de aproximadamente luego 3 200 servidores IRC en todo el mundo. [4] En junio de 2021, se sabe que funcionan 481 redes de IRC diferentes, [5] de las cuales Libera Chat de código abierto, fundada en mayo de 2021, tiene la mayor cantidad de usuarios, con 21,348 canales en 15,433 servidores; entre ellos, las 100 principales redes de IRC comparten 188,336 canales que operan en 96,708 servidores. [6]

Desde un punto de vista técnico, Internet Relay Chat se implementa como un protocolo de capa de aplicación para facilitar la comunicación en forma de texto. El proceso de chat funciona en un modelo de red cliente-servidor . Como ya se ha comentado, los clientes de IRC pueden ser programas informáticos independientes o aplicaciones web que se ejecutan localmente en el navegador o en un servidor de terceros. Estos clientes se comunican con los servidores de chat para transferir mensajes a otros clientes. [7] IRC está diseñado principalmente para la comunicación grupal en foros de discusión, llamados canales , [8] pero también permite la comunicación uno a uno a través de mensajes privados [9] así comochat y transferencia de datos , [10] incluido el intercambio de archivos . [11]

El software cliente está disponible para todos los sistemas operativos principales que admiten el acceso a Internet. [12]

Historia

Ver también: IRCd § Historial

IRC fue creado por Jarkko Oikarinen en agosto de 1988 para reemplazar un programa llamado MUT (MultiUser Talk) en un BBS llamado OuluBox en la Universidad de Oulu en Finlandia , donde trabajaba en el Departamento de Ciencia de Procesamiento de Información. Jarkko tenía la intención de extender el software BBS que administraba, para permitir noticias en el estilo de Usenet , discusiones en tiempo real y características BBS similares. La primera parte que implementó fue la parte del chat, que hizo con partes prestadas escritas por sus amigos Jyrki Kuoppala y Jukka Pihl. La primera red IRC se estaba ejecutando en un solo servidor llamado tolsun.oulu.fi. [13] Oikarinen encontró inspiración en un sistema de chat conocido como Bitnet Relay, que operaba en BITNET . [14]

Jyrki Kuoppala presionó a Oikarinen para que le pidiera a la Universidad de Oulu que liberara el código IRC para que también pudiera ejecutarse fuera de Oulu, y después de que finalmente lo liberaron, Jyrki Kuoppala inmediatamente instaló otro servidor. Esta fue la primera "red IRC". Oikarinen consiguió que algunos amigos de la Universidad de Helsinki y la Universidad de Tampere comenzaran a ejecutar servidores IRC cuando aumentó su número de usuarios y pronto le siguieron otras universidades. En ese momento, Oikarinen se dio cuenta de que el resto de las funciones de BBS probablemente no encajarían en su programa. [13]

Oikarinen se puso en contacto con personas de la Universidad de Denver y la Universidad Estatal de Oregon . Tenían su propia red IRC en funcionamiento y querían conectarse a la red finlandesa. Habían obtenido el programa de uno de los amigos de Oikarinen, Vijay Subramaniam, la primera persona no finlandesa en utilizar IRC. IRC luego se hizo más grande y se usó en toda la red nacional finlandesa, Funet, y luego se conectó a Nordunet , la rama escandinava de Internet. En noviembre de 1988, IRC se había extendido por Internet y, a mediados de 1989, había unos 40 servidores en todo el mundo. [13]

EFnet

En agosto de 1990, tuvo lugar el primer gran desacuerdo en el mundo de la IRC. La "A-net" (red de la anarquía) incluía un servidor llamado eris.berkeley.edu. Todo estaba abierto, no requería contraseñas y no tenía límite en el número de conexiones. Como explica Greg "wumpus" Lindahl: "tenía una línea de servidor comodín, por lo que la gente estaba conectando servidores y colisionando con todo el mundo". La "Eris Free Network", EFnet, convirtió a la máquina eris en la primera en ser revestida con Q (Q para cuarentena) de IRC. En palabras de wumpus nuevamente: "Eris se negó a eliminar esa línea, así que formé EFnet. No fue una gran pelea; conseguí que todos los hubs se unieran, y casi todos los demás se dejaron llevar". A-net se formó con los servidores eris, mientras que EFnet se formó con los servidores que no son eris. El historial mostró que la mayoría de los servidores y usuarios optaron por EFnet. Una vez que A-net se disolvió, el nombre EFnet dejó de tener sentido y, una vez más, fue la única red de IRC. [13]

Por esa época se utilizó el IRC para informar sobre el intento de golpe de Estado soviético de 1991 durante un apagón mediático . [15] Anteriormente se usó de manera similar durante la Guerra del Golfo . [16] Los registros de chat de estos y otros eventos se guardan en el archivo ibiblio . [17]

Horquilla Undernet

Otro esfuerzo de bifurcación, el primero que realmente marcó una diferencia grande y duradera, fue iniciado por 'Wildthang' en los Estados Unidos en octubre de 1992 (bifurcó la versión 2.8.10 de EFnet ircd). Estaba destinado a ser solo una red de prueba para desarrollar bots, pero rápidamente se convirtió en una red "para amigos y sus amigos". En Europa y Canadá se estaba trabajando en una nueva red separada y en diciembre los servidores franceses se conectaron a los canadienses, y a finales de mes, la red francesa y canadiense se conectó a la estadounidense, formando la red que luego vino. que se llamará "The Undernet ". [13]

Los "infranetters" querían llevar la ircd más lejos en un intento de hacer que consumiera menos ancho de banda y tratar de resolver el caos de canales ( netsplits y adquisiciones ) que EFnet comenzó a sufrir. Para este último propósito, Undernet implementó marcas de tiempo, nuevas rutas y ofreció CService, un programa que permitía a los usuarios registrar canales y luego intentaba protegerlos de los alborotadores. La primera lista de servidores presentada, del 15 de febrero de 1993, incluye servidores de EE. UU., Canadá, Francia, Croacia y Japón. El 15 de agosto, el nuevo registro de recuento de usuarios se estableció en 57 usuarios. [13]

En mayo de 1993, RFC 1459 [7] se publicó y detalla un protocolo simple para la operación cliente / servidor, canales, conversaciones uno a uno y uno a muchos. [13] Es notable que un número significativo de extensiones como CTCP, colores y formatos no están incluidas en las especificaciones del protocolo, ni tampoco la codificación de caracteres, [18] lo que llevó a divergir varias implementaciones de servidores y clientes. De hecho, la implementación del software varió significativamente de una red a otra, cada red implementaba sus propias políticas y estándares en sus propias bases de código.

Horquilla DALnet

Durante el verano de 1994, la propia Undernet se bifurcó. La nueva red se llamó DALnet (el nombre de su fundador: dalvenjah), formada para un mejor servicio al usuario y más protecciones para el usuario y el canal. Uno de los cambios más significativos en DALnet fue el uso de apodos más largos (el límite original del ircd era de 9 letras). Alexei "Lefler" Kosut hizo las modificaciones de DALnet ircd. Por tanto, DALnet se basó en el servidor ircd de Undernet, aunque los pioneros de DALnet fueron los que abandonaron EFnet. Según James Ng, las personas iniciales de DALnet eran "operaciones en #StarTrek enfermas por las constantes divisiones / retrasos / adquisiciones / etc.". [13]

DALnet ofreció rápidamente WallOps globales (mensajes IRCop que pueden ser vistos por usuarios que son + w (/ mode NickName + w)), apodos más largos, Q: apodos alineados (apodos que no se pueden usar, es decir, ChanServ, IRCop, NickServ, etc.) , global K: Lines (prohibición de una persona o un dominio completo de un servidor o de toda la red), solo comunicaciones de IRCop: GlobOps, modo + H que muestra que un IRCop es un "helpop", etc. Muchas de las nuevas funciones de DALnet fueron escritas a principios de 1995 por Brian "Morpher" Smith y permiten a los usuarios tener apodos, controlar canales, enviar notas y más. [13]

Bifurcación de IRCnet

En julio de 1996, después de meses de guerras de llamas y discusiones sobre la lista de correo, hubo otra división debido al desacuerdo sobre cómo debería evolucionar el desarrollo de la ircd. Más notablemente, el lado "europeo" (la mayoría de esos servidores estaban en Europa) que luego se denominó IRCnet defendió retrasos en el nick y el canal, mientras que el lado de EFnet defendió las marcas de tiempo. [13] También hubo desacuerdos sobre políticas: la parte europea había comenzado a establecer un conjunto de reglas que dirigían lo que los IRCops podían y no podían hacer, un punto de vista opuesto por la parte estadounidense. [19]

La mayoría (no todos) de los servidores de IRCnet estaban en Europa, mientras que la mayoría de los servidores de EFnet estaban en los EE. UU. Este evento también se conoce como "La Gran Escisión" en muchas sociedades de IRC. EFnet ha crecido desde entonces (en agosto de 1998) y ha superado el número de usuarios que tenía entonces. En el otoño (norte) del año 2000, EFnet tenía unos 50.000 usuarios e IRCnet 70.000. [13]

IRC moderno

IRC ha cambiado mucho a lo largo de su vida en Internet. El nuevo software de servidor ha agregado una multitud de nuevas funciones.

  • Servicios : bots operados en red para facilitar el registro de apodos y canales, envío de mensajes para usuarios fuera de línea y funciones de operador de red.
  • Modos adicionales: mientras que el sistema IRC original usaba un conjunto de modos de canal y de usuario estándar, los nuevos servidores agregan muchos modos nuevos para funciones como eliminar códigos de color del texto, [20] u oscurecer la máscara de host de un usuario ("encubrimiento") para protegerse de Ataques de denegación de servicio . [21]
  • Detección de proxy: la mayoría de los servidores modernos admiten la detección de usuarios que intentan conectarse a través de un servidor proxy inseguro (mal configurado o explotado) , al que luego se le puede negar la conexión. Este software de detección de proxy es utilizado por varias redes, aunque esa lista de proxies en tiempo real no existe desde principios de 2006. [22]
  • Comandos adicionales: los comandos nuevos pueden ser, por ejemplo, comandos abreviados para emitir comandos a los Servicios, o comandos exclusivos del operador de red para manipular la máscara de host de un usuario. [ cita requerida ]
  • Cifrado : para el tramo de cliente a servidor de la conexión, se puede usar TLS (los mensajes dejan de ser seguros una vez que se transmiten a otros usuarios en conexiones estándar, pero dificulta la escucha o las escuchas telefónicas de las sesiones de IRC de un individuo). Para la comunicación de cliente a cliente, se puede utilizar SDCC (Secure DCC). [ cita requerida ]
  • Protocolo de conexión: IRC se puede conectar a través de IPv4 , la versión anterior del Protocolo de Internet , o por IPv6 , el estándar actual del protocolo.

A partir de 2016 , se está llevando a cabo un nuevo esfuerzo de estandarización bajo un grupo de trabajo llamado IRCv3, que se enfoca en funciones de cliente más avanzadas como notificaciones instantáneas, mejor soporte de historial y seguridad mejorada. [23] A partir de 2019 , ninguna de las principales redes de IRC ha adoptado por completo el estándar propuesto. [24]

Después de su era dorada durante la década de 1990 y principios de la de 2000 (240.000 usuarios en QuakeNet en 2004), IRC ha experimentado una disminución significativa, perdiendo alrededor del 60% de los usuarios entre 2003 y 2012, y los usuarios se mudaron a plataformas de redes sociales más nuevas como Facebook o Twitter . [2] sino también a plataformas abiertas como XMPP, que se desarrolló en 1999. Ciertas redes como Freenode no han seguido la tendencia general y han cuadruplicado su tamaño durante el mismo período. [2] Sin embargo, Freenode, que en 2016 tenía alrededor de 90.000 usuarios, desde entonces se ha reducido a unos 65.000 usuarios. [25]

Las redes de IRC más grandes se han agrupado tradicionalmente como las "Cuatro Grandes" [26] [27] [28] [29], una designación para las redes que encabezan las estadísticas. Las cuatro grandes redes cambian periódicamente, pero debido a la naturaleza comunitaria de IRC, hay una gran cantidad de otras redes entre las que los usuarios pueden elegir.

Históricamente, los "Cuatro Grandes" fueron: [26] [27] [28]

  • EFnet
  • IRCnet
  • Undernet
  • DALnet

IRC llegó a 6 millones de usuarios simultáneos en 2001 y 10 millones de usuarios en 2003, cayendo a 371.000 en 2018. [ cita requerida ]

A octubre de 2018 , las redes de IRC más grandes son:

  • freenode  : alrededor de 90.000 usuarios en las horas pico
  • IRCnet  : alrededor de 30.000 usuarios en las horas pico
  • EFnet  : alrededor de 18.000 usuarios en las horas pico
  • Undernet  : alrededor de 17.000 usuarios en las horas pico
  • QuakeNet  : alrededor de 15.000 usuarios en las horas pico
  • Rizon  : alrededor de 14.000 usuarios en las horas pico
  • OFTC  : alrededor de 13k usuarios en las horas pico
  • DALnet  : alrededor de 8.000 usuarios en las horas pico

Hoy en día, las 100 principales redes de IRC tienen alrededor de 370.000 usuarios conectados en las horas pico. [30]

Cronología

Cronología de los principales servidores:

  • EFnet , 1990 al presente
  • Undernet , 1992 al presente
  • DALnet , 1994 al presente
  • freenode , 1995 al presente
  • IRCnet , 1996 al presente
  • QuakeNet , 1997 al presente
  • Comunidad de tecnología abierta y libre , 2001 al presente
  • Rizon , 2002 al presente
  • Libera Chat , 2021 al presente

Información técnica

Ver también: IRCd
Una captura de pantalla de HexChat , un cliente de IRC para entornos GTK .
Xaric, un cliente de IRC basado en texto, en el uso de Mac OS X . Se muestran dos canales de IRC y una conversación privada con el autor del software.

IRC es un protocolo abierto que usa TCP [7] y, opcionalmente, TLS . Un servidor de IRC puede conectarse a otros servidores de IRC para expandir la red de IRC. [31] Los usuarios acceden a las redes IRC conectando un cliente a un servidor. [32] Hay muchas implementaciones de cliente, como mIRC , HexChat e irssi , e implementaciones de servidor, por ejemplo, el IRCd original . La mayoría de los servidores de IRC no requieren que los usuarios registren una cuenta, pero se requiere un nick antes de conectarse. [33]

IRC fue originalmente un protocolo simple de texto [7] (aunque más tarde ampliada), que a petición fue asignado puerto 194 / TCP por IANA . [34] Sin embargo, el estándar de facto siempre ha sido ejecutar IRC en 6667 / TCP [35] y números de puerto cercanos (por ejemplo, puertos TCP 6660-6669, 7000) [36] para evitar tener que ejecutar el software IRCd con root privilegios .

El protocolo especificaba que los caracteres eran de 8 bits, pero no especificaba la codificación de caracteres que se suponía que debía usar el texto. [18] Esto puede causar problemas cuando los usuarios que utilizan diferentes clientes y / o diferentes plataformas desean conversar.

Todos los protocolos de IRC de cliente a servidor que se utilizan hoy en día descienden del protocolo implementado en la versión irc2.4.0 del servidor IRC2 y están documentados en RFC 1459. Desde que se publicó RFC 1459, las nuevas características de la implementación de irc2.10 llevaron a la publicación de varios documentos de protocolo revisados ​​(RFC 2810, RFC 2811, RFC 2812 y RFC 2813); sin embargo, estos cambios de protocolo no se han adoptado ampliamente entre otras implementaciones. [ cita requerida ]

Aunque se han publicado muchas especificaciones sobre el protocolo IRC, no existe una especificación oficial, ya que el protocolo sigue siendo dinámico. Prácticamente ningún cliente y muy pocos servidores se basan estrictamente en las RFC anteriores como referencia. [ cita requerida ]

Microsoft hizo una extensión para IRC en 1998 a través del IRCX propietario . [37] Posteriormente dejaron de distribuir software compatible con IRCX y, en su lugar, desarrollaron el MSNP propietario .

La estructura estándar de una red de servidores IRC es un árbol . [38] Los mensajes se enrutan solo a lo largo de las ramas necesarias del árbol, pero el estado de la red se envía a todos los servidores [39] y, en general, existe un alto grado de confianza implícita entre los servidores. Sin embargo, esta arquitectura tiene varios problemas. Un servidor malintencionado o que se porta mal puede causar un daño importante a la red [40] y cualquier cambio en la estructura, ya sea intencional o como resultado de las condiciones de la red subyacente, requiere una división y una unión a la red. Esto da como resultado una gran cantidad de tráfico de red y mensajes falsos para salir / unirse a los usuarios [41]y pérdida temporal de comunicación con los usuarios en los servidores de división. Agregar un servidor a una red grande significa una gran carga de ancho de banda de fondo en la red y una gran carga de memoria en el servidor. Sin embargo, una vez establecido, cada mensaje a varios destinatarios se envía de forma similar a la multidifusión , lo que significa que cada mensaje viaja por un enlace de red exactamente una vez. [42] Esta es una fortaleza en comparación con los protocolos que no son de multidifusión, como el Protocolo simple de transferencia de correo (SMTP) [ cita requerida ] o el Protocolo extensible de mensajería y presencia (XMPP) [ cita requerida ] .

Un demonio de IRC también se puede utilizar en una red de área local (LAN). Por tanto, el IRC se puede utilizar para facilitar la comunicación entre personas dentro de la red de área local (comunicación interna). [43] [44]

Comandos y respuestas

Artículo principal: Lista de comandos de Internet Relay Chat

IRC tiene una estructura basada en líneas. Los clientes envían mensajes de una sola línea al servidor, [45] reciben respuestas a esos mensajes [46] y reciben copias de algunos mensajes enviados por otros clientes. En la mayoría de los clientes, los usuarios pueden ingresar comandos prefijándolos con una '/'. Dependiendo del comando, estos pueden ser manejados completamente por el cliente o (generalmente para comandos que el cliente no reconoce) pasados ​​directamente al servidor, posiblemente con alguna modificación. [ cita requerida ]

Debido a la naturaleza del protocolo, los sistemas automatizados no siempre pueden emparejar correctamente un comando enviado con su respuesta con total fiabilidad y están sujetos a conjeturas. [47]

Canales

El medio básico de comunicarse con un grupo de usuarios en una sesión de IRC establecida es a través de un canal . [48] ​​Los canales en una red se pueden mostrar usando el comando IRC LIST , [49] que enumera todos los canales actualmente disponibles que no tienen los modos + so + p configurados, en esa red en particular.

Los usuarios pueden unirse a un canal usando el comando JOIN , [50] en la mayoría de los clientes disponible como / join #channelname . Los mensajes enviados a los canales unidos se transmiten a todos los demás usuarios. [48]

Los canales que están disponibles en toda una red IRC tienen el prefijo '#', mientras que los locales de un servidor usan '&'. [51] Otros tipos de canales menos comunes incluyen canales '+', canales 'sin modo' sin operadores [52] y '!' canales, una forma de sellos de tiempo de canal en redes normalmente no sellos de tiempo. [53]

Modos

Los usuarios y los canales pueden tener modos representados por letras que distinguen entre mayúsculas y minúsculas [54] y se configuran mediante el comando MODE . [55] Los modos de usuario y los modos de canal están separados y pueden usar la misma letra para significar cosas diferentes (por ejemplo, el modo de usuario "i" es un modo invisible mientras que el modo de canal "i" es solo por invitación. [56] ) Los modos generalmente se configuran y desarman usando el comando de modo que toma un objetivo (usuario o canal), un conjunto de modos para armar (+) o desarmar (-) y cualquier parámetro que los modos necesiten.

Algunos modos de canal toman parámetros y otros modos de canal se aplican a un usuario en un canal o agregan o eliminan una máscara (por ejemplo, una máscara de prohibición) de una lista asociada con el canal en lugar de aplicarla al canal como un todo. [57] Los modos que se aplican a los usuarios en un canal tienen un símbolo asociado que se usa para representar el modo en las respuestas de nombres [58] (enviado a los clientes al unirse por primera vez a un canal [50] y al usar el comando de nombres) y en muchos los clientes también solían representarlo en la lista de usuarios mostrada por el cliente en un canal o para mostrar un indicador propio para los modos de un usuario.

Para analizar correctamente los mensajes de modo entrantes y rastrear el estado del canal, el cliente debe saber qué modo es de qué tipo y para los modos que se aplican a un usuario en un canal, qué símbolo va con qué letra. En las primeras implementaciones de IRC, esto tenía que estar codificado en el cliente, pero ahora hay una extensión estándar de facto del protocolo llamada ISUPPORT que envía esta información al cliente en el momento de la conexión utilizando el número 005. [59] [60]

Hay una pequeña falla de diseño en el IRC con respecto a los modos que se aplican a los usuarios en los canales: el mensaje de nombres que se usa para establecer el estado inicial del canal solo puede enviar uno de esos modos por usuario en el canal, [58] pero varios de estos modos se pueden configurar en un usuario unico. Por ejemplo, si un usuario tiene tanto el estado de operador (+ o) como el estado de voz (+ v) en un canal, un nuevo cliente no podrá ver el modo con menos prioridad (es decir, voz). Las soluciones para esto son posibles tanto en el lado del cliente como en el del servidor, pero ninguna está ampliamente implementada.

Modos estándar (RFC 1459)

Modos de usuario
CartaSímboloDescripción
IInvisible: no se puede ver sin un canal común o sin conocer el nombre exacto
sRecibe avisos del servidor
wRecibe golpes [61]
oEl usuario es un operador de IRC (ircop)
Modos de canal
CartaSímboloParámetro (s)Descripción
o@Nombre del usuario afectadoOperador de canal: puede cambiar los modos de canal y expulsar a los usuarios del canal, entre otras cosas.
sCanal secreto: no se muestra en la lista de canales ni en el whois del usuario, excepto para los usuarios que ya están en el canal.
pagCanal privado: listado en la lista de canales como "prv" según RFC 1459.
norteLos usuarios no pueden enviar mensajes al canal de forma externa
metroEl canal está moderado (solo aquellos que tienen el operador del canal o el estado de voz en el canal pueden enviarle mensajes)
ISolo los usuarios con invitaciones pueden ingresar al canal.
tSolo los operadores de canal pueden cambiar el tema del canal.
lNúmero límiteLimita la cantidad de usuarios que pueden estar en el canal (cuando está lleno, no pueden unirse nuevos usuarios)
BMáscara de prohibición (nick! User @ host con comodines permitidos)Prohibe las máscaras de host del canal
v+Nombre del usuario afectadoDa un estado de voz de usuario en el canal (ver + m arriba)
kNueva clave de canalEstablece una clave de canal de manera que solo los usuarios que conocen la clave pueden ingresar

Muchos demonios y redes han agregado modos adicionales o han modificado el comportamiento de los modos en la lista anterior. [62] [63] [64] [65]

Operadores de canal

Un operador de canal es un cliente en un canal de IRC que administra el canal. Los operadores de canales de IRC pueden verse fácilmente por el símbolo o icono junto a su nombre (varía según la implementación del cliente, comúnmente un prefijo de símbolo "@", un círculo verde o una letra latina "+ o" / "o"). En la mayoría de las redes, un operador puede:

  • Expulsar a un usuario
  • Prohibir a un usuario
  • Otorgue a otro usuario el estado de operador del canal IRC o el estado de voz del canal IRC.
  • Cambie el tema del canal IRC mientras el modo de canal + t está configurado.
  • Cambie los bloqueos del modo de canal de IRC.

Operadores de IRC

Artículo principal: operador de chat de retransmisión de Internet

También hay usuarios que mantienen derechos elevados en su servidor local o en toda la red; estos se denominan operadores IRC, [66] a veces abreviados como IRCops u Opers (que no deben confundirse con operadores de canal). A medida que varía la implementación del IRCd, también lo hacen los privilegios del operador de IRC en el IRCd dado. RFC 1459 [66]afirma que los operadores de IRC son "un mal necesario" para mantener un estado limpio de la red y, como tal, necesitan poder desconectar y volver a conectar los servidores. Además, para evitar que usuarios malintencionados o incluso programas automatizados dañinos ingresen al IRC, los operadores de IRC generalmente pueden desconectar clientes y prohibir completamente las direcciones IP o las subredes completas. Las redes que transportan servicios (NickServ et al.) Generalmente permiten que sus operadores de IRC también manejen asuntos básicos de "propiedad". Otros derechos privilegiados pueden incluir la anulación de las prohibiciones de canales (poder unirse a canales a los que no se les permitiría unirse, si no estuvieran abiertos), poder optar por sí mismos en canales donde no podrían sin ser operados, ser auto-optado en los canales siempre y así sucesivamente.

Máscaras de host

Una máscara de host es un identificador único de un cliente de IRC conectado a un servidor de IRC . [67] [68] Los servidores , servicios y otros clientes de IRC , incluidos los bots , pueden usarlo para identificar una sesión de IRC específica.

El formato de una máscara de host es nick!user@host. La máscara de host tiene un aspecto similar, pero no debe confundirse con una dirección de correo electrónico .

La parte del apodo es el apodo elegido por el usuario y se puede cambiar mientras está conectado. La parte del usuario es el nombre de usuario informado por ident en el cliente. [69] Si ident no está disponible en el cliente, el nombre de usuario especificado cuando el cliente se conectó se usa después de tener un prefijo con una tilde . [70]

La parte del host es el nombre de host desde el que se conecta el cliente. Si el servidor no puede resolver la dirección IP del cliente en un nombre de host válido , se utiliza en lugar del nombre de host.

Debido a las implicaciones de privacidad de exponer la dirección IP o el nombre de host de un cliente, algunos demonios de IRC también proporcionan características de privacidad, como InspIRCd o el modo "+ x" de UnrealIRCd. Esto codifica la dirección IP de un cliente o enmascara parte del nombre de host de un cliente, haciéndolo ilegible para otros usuarios que no sean IRCops . Los usuarios también pueden tener la opción de solicitar un "host virtual" (o "vhost"), que se mostrará en la máscara de host para permitir un mayor anonimato. Algunas redes de IRC, como Freenode, las utilizan como "capas" para indicar que un usuario está afiliado a un grupo o proyecto. [71]

Esquema de URI

Hay tres reconocidos identificador uniforme de recursos (URI) esquemas para Internet Relay Chat: irc, ircs, y irc6. [72] Cuando son compatibles, permiten hipervínculos de varias formas, incluidos

irc: // <host> [: <puerto>] / [<canal> [? <palabra clave_canal>]]
ircs: // <host> [: <puerto>] / [<canal> [? <palabra clave_canal>]]
irc6: // <host> [: <puerto>] / [<canal> [? <palabra clave_canal>]]

(donde los elementos encerrados entre corchetes ([,]) son opcionales) para ser usados ​​(si es necesario) para conectarse al host especificado (o red, si lo conoce el cliente IRC) y unirse al canal especificado. [73] (Esto se puede utilizar dentro del propio cliente o desde otra aplicación, como un navegador web). irc es el URI predeterminado, irc6 especifica una conexión que se realizará mediante IPv6 e ircs especifica una conexión segura.

Según la especificación, el símbolo de almohadilla habitual (#) se antepondrá a los nombres de los canales que comienzan con un carácter alfanumérico , lo que permite omitirlo. Algunas implementaciones (por ejemplo, mIRC) lo harán incondicionalmente dando como resultado un extra (generalmente no intencionado) (por ejemplo, ## canal), si se incluye en la URL.

Algunas implementaciones permiten especificar varios canales, separados por comas. [74]

Desafíos

Los problemas en el diseño original de IRC fueron la cantidad de datos de estado compartidos [75] [76] que son una limitación en su escalabilidad, [77] la ausencia de identificaciones de usuario únicas que conducen al problema de colisión de apodos, [78] falta de protección contra netsplits por medio de enrutamiento cíclico, [79] [80] la compensación en la escalabilidad por el bien de la información de presencia del usuario en tiempo real, [81] debilidades del protocolo que proporcionan una plataforma para el abuso, [82] sin paso de mensajes transparente y optimizable , [83] y sin cifrado. [84] Algunas de estas cuestiones se han abordado en Modern IRC .

Ataques

Debido a que las conexiones de IRC pueden no estar cifradas y generalmente abarcan períodos de tiempo prolongados, son un objetivo atractivo para los atacantes y piratas informáticos DoS / DDoS . Debido a esto, es necesaria una política de seguridad cuidadosa para garantizar que una red de IRC no sea susceptible a un ataque como una guerra de adquisición . Las redes de IRC también pueden ser usuarios o servidores de K-line o G-line que tienen un efecto perjudicial.

Algunos servidores de IRC admiten conexiones SSL / TLS por motivos de seguridad. Esto ayuda a detener el uso de programas de rastreo de paquetes para obtener las contraseñas de los usuarios de IRC, pero tiene poco uso fuera de este alcance debido a la naturaleza pública de los canales de IRC. Las conexiones SSL requieren soporte tanto del cliente como del servidor (que puede requerir que el usuario instale binarios SSL y parches o módulos específicos del cliente IRC en sus computadoras). Algunas redes también utilizan SSL para conexiones de servidor a servidor y proporcionan una marca de canal especial (como +S) para permitir solo a los usuarios conectados a SSL en el canal, mientras que no permiten la identificación del operador en texto claro, para aprovechar mejor las ventajas que proporciona SSL . [85] [86]

IRC sirvió como un laboratorio temprano para muchos tipos de ataques de Internet, como el uso de mensajes ICMP inalcanzables falsos para romper las conexiones IRC basadas en TCP ( nuking ) para molestar a los usuarios o facilitar las adquisiciones .

Prevención de abusos

Uno de los problemas técnicos más polémicos que rodean las implementaciones de IRC, que sobrevive hasta el día de hoy, es el mérito de los protocolos "Nick / Channel Delay" frente a los protocolos "Timestamp". Ambos métodos existen para resolver el problema de los ataques de denegación de servicio, pero adoptan enfoques muy diferentes. El problema con el protocolo IRC original implementado era que cuando dos servidores se dividían y volvían a unirse, los dos lados de la red simplemente fusionaban sus canales. Si un usuario pudiera unirse a un servidor "dividido", donde un canal que existía en el otro lado de la red estaba vacío, y obtener el estado de operador, se convertiría en un operador de canal del canal "combinado" después del netsplit.terminó si un usuario tomaba un apodo que existía en el otro lado de la red, el servidor mataría a ambos usuarios cuando se reincorporaran (es decir, 'nick-collision'). A menudo se abusaba de esto para "matar en masa" a todos los usuarios de un canal, creando así canales "sin acceso" en los que no había operadores presentes para hacer frente al abuso. Además de causar problemas dentro de IRC, esto alentó a las personas a realizar ataques de denegación de servicio contra servidores de IRC para causar netsplits , que luego abusarían.

Las estrategias de retardo de nick (ND) y retardo de canal (CD) tienen como objetivo prevenir el abuso retrasando las reconexiones y los cambios de nombre. Después de que un usuario cierra la sesión y el apodo está disponible, o un canal deja de existir porque todos sus usuarios se separaron (como sucede a menudo durante un netsplit ), el servidor no permitirá que ningún usuario use ese apodo o se una a ese canal, hasta cierto ha pasado un período de tiempo (el retraso ). La idea detrás de esto es que incluso si un netsplitocurre, es inútil para un abusador porque no puede tomar el apodo u obtener el estatus de operador en un canal y, por lo tanto, no puede ocurrir una colisión de un apodo o una "fusión" de un canal. Hasta cierto punto, esto incomoda a los usuarios legítimos, que podrían verse obligados a usar brevemente un nombre diferente después de volver a unirse (es común agregar un guión bajo ).

El protocolo de marca de tiempo es una alternativa a los retrasos de nick / canal que resuelve colisiones utilizando la prioridad de marca de tiempo. A cada apodo y canal de la red se le asigna una marca de tiempo: la fecha y la hora en que se creó. Cuando ocurre un netsplit, dos usuarios de cada lado son libres de usar el mismo apodo o canal, pero cuando los dos lados están unidos, solo uno puede sobrevivir. En el caso de los apodos, el usuario más nuevo, según su TS, muere; cuando un canal choca, los miembros (usuarios del canal) se fusionan, pero los operadores del canal en el lado "perdedor" de la división pierden su condición de operador de canal.

TS es un protocolo mucho más complicado que ND / CD, tanto en diseño como en implementación, y a pesar de haber pasado por varias revisiones, algunas implementaciones todavía tienen problemas con "desincronizaciones" (donde dos servidores en la misma red no están de acuerdo con el estado actual de la red), y permitir demasiada indulgencia en lo que permitía el lado 'perdedor'. Bajo los protocolos TS originales, por ejemplo, no había protección contra los usuarios que establecían prohibiciones u otros modos en el canal perdedor que luego se fusionarían cuando la división se reincorporara, a pesar de que los usuarios que habían configurado esos modos perdieron su estado de operador de canal. Algunos servidores IRC modernos basados ​​en TS también han incorporado alguna forma de ND y / o CD además de la marca de tiempo en un intento de frenar aún más el abuso.

La mayoría de las redes actuales utilizan el enfoque de sellado de tiempo. Los desacuerdos entre la marca de tiempo y ND / CD hicieron que varios servidores se separaran de EFnet y formaran la IRCnet más nueva . Después de la división, EFnet pasó a un protocolo TS, mientras que IRCnet usó ND / CD.

En versiones recientes de IRCnet ircd, así como ircds que usan el protocolo TS6 (incluido Charybdis), ND se ha extendido / reemplazado por un mecanismo llamado SAVE. Este mecanismo asigna a cada cliente un UID al conectarse a un servidor IRC. Este ID comienza con un número, que está prohibido en los nicks (aunque algunos ircds, a saber, IRCnet e InspIRCd, permiten a los clientes cambiar a su propio UID como apodo).

Si dos clientes con el mismo apodo se unen desde diferentes lados de un netsplit ("colisión de nick"), el primer servidor que vea esta colisión forzará a ambos clientes a cambiar su nick a su UID, evitando así que ambos clientes se desconecten. En IRCnet, el apodo también se bloqueará durante algún tiempo (ND) para evitar que ambos clientes vuelvan a cambiar al apodo original y, por lo tanto, vuelvan a colisionar.

Clientela

Software de cliente

Más información: Comparación de clientes de Internet Relay Chat
Esquema de una red IRC con clientes normales (verde), bots (azul) y gorilas (naranja)

El software cliente existe para varios sistemas operativos o paquetes de software, así como para juegos internos o basados ​​en la web. Hay muchos clientes diferentes disponibles para los distintos sistemas operativos, incluidos Windows , Unix y Linux , macOS y sistemas operativos móviles (como iOS y Android ). En Windows, mIRC es uno de los clientes más populares. [87]

Algunos programas que se pueden ampliar a través de complementos también sirven como plataformas para los clientes de IRC. Por ejemplo, un cliente llamado ERC , escrito completamente en Emacs Lisp , está incluido en la v.22.3 de Emacs. Por lo tanto, cualquier plataforma que pueda ejecutar Emacs puede ejecutar ERC.

Varios navegadores web tienen clientes IRC integrados, como Opera ( versión 12.18 y anteriores ) [88] y el complemento ChatZilla para Mozilla Firefox (para Firefox 56 y anteriores; incluido como componente integrado de SeaMonkey ) . Los clientes basados ​​en web, como Mibbit y KiwiIRC de código abierto, pueden ejecutarse en la mayoría de los navegadores.

Juegos como War§ow , [89] Unreal Tournament (hasta Unreal Tournament 2004 ), [90] Uplink , [91] juegos basados ​​en Spring Engine , 0 AD y ZDaemon han incluido IRC. [92]

La interfaz de chat de Ustream es IRC con autenticación personalizada [93] , así como la de Twitch (anteriormente Justin.tv). [94] [95]

Bots

Artículo principal: bot de IRC

Un uso típico de los bots en IRC es proporcionar servicios de IRC o funcionalidad específica dentro de un canal, como albergar un juego basado en chat o proporcionar notificaciones de eventos externos. Sin embargo, algunos bots de IRC se utilizan para lanzar ataques maliciosos como denegación de servicio, spam o explotación. [96]

Bravucón

Artículo principal: BNC (software)

Un programa que se ejecuta como un demonio en un servidor y funciona como un proxy persistente se conoce como BNC o bouncer. El propósito es mantener una conexión a un servidor de IRC, actuando como un relé entre el servidor y el cliente, o simplemente para actuar como un proxy. [ cita requerida ] Si el cliente pierde la conectividad de la red, el BNC puede permanecer conectado y archivar todo el tráfico para una entrega posterior, lo que permite al usuario reanudar su sesión de IRC sin interrumpir su conexión con el servidor. [97]

Además, como una forma de obtener un efecto de rebote, un cliente de IRC (típicamente basado en texto , por ejemplo Irssi ) se puede ejecutar en un servidor siempre activo al que el usuario se conecta a través de ssh . Esto también permite que los dispositivos que solo tienen funcionalidad ssh, pero ningún cliente IRC real instalado ellos mismos, se conecten al IRC, y permite compartir sesiones de IRC. [98]

Para evitar que el cliente IRC se cierre cuando se cierra la conexión ssh, el cliente se puede ejecutar dentro de un multiplexor de terminal como GNU Screen o tmux , permaneciendo así conectado a la (s) red (s) IRC constantemente y capaz de registrar la conversación en los canales que el usuario está interesado o para mantener la presencia de un canal en la red. Siguiendo el modelo de esta configuración, en 2004 se lanzó un cliente IRC que sigue al cliente-servidor , llamado Smuxi . [99] [100]

Los motores de búsqueda

Hay numerosos motores de búsqueda disponibles para ayudar al usuario a encontrar lo que busca en IRC. [101] [102] Generalmente, el motor de búsqueda consta de dos partes, un "back-end" (o "araña / rastreador") y un "motor de búsqueda" front-end.

El back-end (spider / webcrawler) es el caballo de batalla del motor de búsqueda. Es responsable de rastrear los servidores de IRC para indexar la información que se envía a través de ellos. La información que se indexa generalmente consiste únicamente en el texto del canal (texto que se muestra públicamente en los canales públicos). El método de almacenamiento suele ser algún tipo de base de datos relacional, como MySQL u Oracle . [ cita requerida ]

El "motor de búsqueda" de front-end es la interfaz de usuario de la base de datos. Proporciona a los usuarios una forma de buscar en la base de datos de información indexada para recuperar los datos que están buscando. Estos motores de búsqueda front-end también se pueden codificar en numerosos lenguajes de programación.

La mayoría de los motores de búsqueda tienen su propia araña que es una única aplicación responsable de rastrear el IRC y de indexar los datos en sí; sin embargo, otros son indexadores "basados ​​en el usuario". Estos últimos dependen de los usuarios para instalar su "complemento" en su cliente de IRC; el complemento es lo que envía a la base de datos la información del canal de cualquier canal en el que se encuentre el usuario. [ cita requerida ]

Muchos usuarios han implementado sus propios motores de búsqueda ad hoc utilizando las funciones de registro integradas en muchos clientes de IRC. Estos motores de búsqueda generalmente se implementan como bots y se dedican a un canal en particular o grupo de canales asociados.

Codificación de caracteres

IRC todavía carece de una convención estándar única aceptada a nivel mundial sobre cómo transmitir caracteres fuera del repertorio ASCII de 7 bits . Los servidores de IRC normalmente [ aclaración necesaria ] transfieren mensajes de un cliente a otro cliente como secuencias de bytes, sin ninguna interpretación o recodificación de caracteres . El protocolo IRC (a diferencia de, por ejemplo, MIME o HTTP ) carece de mecanismos para anunciar y negociar opciones de codificación de caracteres. Esto ha puesto la responsabilidad de elegir el códec de caracteres apropiado en el cliente. En la práctica, los canales de IRC han utilizado en gran medida las mismas codificaciones de caracteres que también utilizaban los sistemas operativos (en particular, Unix derivados) en las respectivas comunidades lingüísticas:

  • Era de 7 bits: en los primeros días de IRC, especialmente entre los usuarios de idiomas escandinavos y finlandeses , las variantes nacionales de ISO 646 eran las codificaciones de caracteres dominantes . Estos codifican caracteres no ASCII como Ä Ö Å ä ö å en las posiciones de código 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ( US-ASCII : [ \ ] { | } ). Es por eso que estos códigos siempre están permitidos en los apodos. Según RFC 1459, {| } en los apodos deben tratarse como equivalentes en minúsculas de [\] respectivamente. [18] A finales de la década de 1990, el uso de codificaciones de 7 bits había desaparecido en favor de ISO 8859-1., y esas asignaciones de equivalencia se eliminaron de algunos demonios de IRC.
  • Era de los 8 bits: desde principios de la década de 1990, las codificaciones de 8 bits, como ISO 8859-1, se han vuelto de uso común para los idiomas europeos. Los usuarios rusos tenían la opción de KOI8-R , ISO 8859-5 [ cita requerida ] y CP1251 , y desde aproximadamente el año 2000, las redes IRC rusas modernas convierten entre estas diferentes codificaciones de escritura cirílica de uso común .
  • Era de varios bytes: durante mucho tiempo, los canales de IRC de Asia oriental con guiones logográficos en China, Japón y Corea han estado utilizando codificaciones de varios bytes como EUC o ISO-2022-JP . Con la migración común de ISO 8859 a UTF-8 en plataformas Linux y Unix desde aproximadamente 2002, UTF-8 se ha convertido en un sustituto cada vez más popular de muchas de las codificaciones de 8 bits utilizadas anteriormente en los canales europeos. Algunos clientes de IRC ahora son capaces de leer mensajes tanto en ISO 8859-1 como en UTF-8 en el mismo canal, autodetectando heurísticamente qué codificación se usa. El cambio a UTF-8 comenzó en particular en el IRC de habla finlandesa ( Merkistö (finlandés) ).

Hoy en día, la codificación UTF-8 de Unicode / ISO 10646 sería el contendiente más probable para una codificación de caracteres estándar única en el futuro para toda la comunicación IRC, si tal estándar alguna vez relajó la restricción de tamaño de mensaje de 510 bytes. UTF-8 es compatible con ASCII y cubre el superconjunto de todos los demás estándares de juegos de caracteres codificados de uso común .

Compartición de archivos

Al igual que el intercambio de archivos P2P convencional , los usuarios pueden crear servidores de archivos que les permitan compartir archivos entre sí mediante el uso de scripts o bots de IRC personalizados para su cliente de IRC . A menudo, los usuarios se agrupan para distribuir warez a través de una red de bots de IRC. [103]

Técnicamente, IRC no proporciona mecanismos de transferencia de archivos en sí; El intercambio de archivos es implementado por los clientes de IRC , normalmente utilizando el protocolo Direct Client-to-Client (DCC), en el que las transferencias de archivos se negocian mediante el intercambio de mensajes privados entre clientes. La gran mayoría de los clientes de IRC cuentan con soporte para transferencias de archivos DCC, de ahí la opinión de que el intercambio de archivos es una característica integral de IRC. [104] Sin embargo, el uso común de este protocolo a veces también causa spam DCC. Los comandos DCC también se han utilizado para explotar a los clientes vulnerables para que realicen una acción como desconectarse del servidor o salir del cliente.

Ver también

  • Sala de chat
  • Protocolo de cliente a cliente
  • Comparación de protocolos de mensajería instantánea
  • Comparación de clientes de IRC
  • Comparación de clientes de IRC móviles
  • Los jugadores de Hamnet
  • jerga de Internet
  • Lista de comandos de IRC
  • Canal de servicio

Citas

  1. ^ Jarkko Oikarinen, Darren Reed. " RFC 1459, Protocolo de chat de retransmisión de Internet ", mayo de 1993. Consultado el 12 de junio de 2021.
  2. ^ a b c "El IRC está muerto, viva el IRC" . Pingdom . 24 de abril de 2012 . Consultado el 25 de abril de 2016 .
  3. ^ a b c "Redes IRC - Top 100" . irc.netsplit.de . Consultado el 8 de abril de 2011 .
  4. ^ "Servidores IRC - Resumen" . irc.netsplit.de. Archivado desde el original el 22 de abril de 2011 . Consultado el 8 de abril de 2011 .
  5. ^ " Redes IRC - en orden alfabético ", 2020, netsplit.de. Consultado el 12 de junio de 2021.
  6. ^ " Redes de IRC - Top 100 ", 2020, netsplit.de. Consultado el 12 de junio de 2021.
  7. ^ a b c d "Introducción" . Protocolo de chat de retransmisión de Internet . pag. 4. seg. 1. doi : 10.17487 / RFC1459 . RFC 1459 .
  8. ^ "Uno a muchos" . Protocolo de chat de retransmisión de Internet . pag. 11. seg. 3.2. doi : 10.17487 / RFC1459 . RFC 1459 .
  9. ^ "Comunicación uno a uno" . Chat de retransmisión de Internet: Arquitectura . pag. 5. seg. 5.1. doi : 10.17487 / RFC2810 . RFC 2810 .
  10. ^ Rollo, Troya. "Una descripción del protocolo DCC" . irchelp.org . Consultado el 8 de abril de 2011 .
  11. ^ Wang, Wallace (25 de octubre de 2004). "Mensajería instantánea y salas de chat en línea: Internet Relay Chat (IRC)" . Robar este libro de intercambio de archivos (1ª ed.). San Francisco, California : No Starch Press . págs.  61–67 . ISBN 978-1-59327-050-6.
  12. ^ "Canal de IRC SAGE" . Sage: el grupo de interés especial de USENIX para administradores de sistemas. Archivado desde el original el 7 de febrero de 2012 . Consultado el 18 de abril de 2011 .
  13. ↑ a b c d e f g h i j k Stenberg, Daniel (29 de marzo de 2011). "Historia de IRC (Internet Relay Chat)" . Consultado el 25 de abril de 2016 . No experimenté todo esto. Encontré información sobre varios lugares y recibí información de varias personas para poder escribir esto. Entre las personas que me han ayudado con esto se incluyen: Greg "wumpus" Lindahl, Vesa "vesa" Ruokonen, James Ng, Tuomas Heino, Richard (eagle`s on undernet), Ari Lemmke
  14. ^ Oikarinen, Jarkko . "Fundación IRC" . Consultado el 8 de abril de 2011 .
  15. ^ "Transcripciones del IRC desde el momento del intento de golpe de Estado soviético de 1991" . Chapel Hill, Carolina del Norte : ibiblio . Archivado desde el original el 28 de junio de 2009 . Consultado el 8 de abril de 2011 .
  16. ^ "Registros del IRC de eventos de la Guerra del Golfo" . Chapel Hill, Carolina del Norte : ibiblio . Consultado el 8 de abril de 2011 .
  17. ^ "Registros de eventos importantes en la comunidad en línea" . Chapel Hill, Carolina del Norte : ibiblio . Consultado el 8 de abril de 2011 .
  18. ^ a b c "Códigos de caracteres" . Protocolo de chat de retransmisión de Internet . pag. 7. seg. 2.2. doi : 10.17487 / RFC1459 . RFC 1459 .
  19. ^ Engen, Vegard (mayo de 2000). "La Gran Escisión" . IRC.org . Consultado el 25 de abril de 2016 .
  20. ^ "Modos de canal" . Wiki de documentación de UnrealIRCd . Consultado el 6 de enero de 2018 .
  21. ^ "Encubrimiento" . Wiki de documentación de UnrealIRCd . Consultado el 6 de enero de 2018 .
  22. ^ "Blitzed Open Proxy Monitor se apaga" . El Open Proxy Monitor proporcionado por la red IRC de Blitzed ha sido cerrado ... La base de datos era tan grande que es casi imposible para el equipo hacer una copia de seguridad o encontrar una nueva ubicación para continuar con el servicio. Sumado a eso, la mayoría de los miembros del equipo ya no tienen tiempo para mantener el servicio en funcionamiento.
  23. ^ "IRCv3" . Grupo de trabajo IRCv3. 2016 . Consultado el 25 de abril de 2016 . El Grupo de Trabajo IRCv3 es una colección de autores de software de servidor y cliente IRC que trabajan para mejorar, mantener y estandarizar el protocolo IRC utilizando extensiones compatibles con versiones anteriores.
  24. ^ "Redes - IRCv3" . 2019 . Consultado el 9 de agosto de 2019 .
  25. ^ "netsplit.de top 10" . Consultado el 12 de junio de 2021 .
  26. ↑ a b Charalabidis, Alex (15 de diciembre de 1999). "IRC en Macintosh: Ircle". The Book of IRC: The Ultimate Guide to Internet Relay Chat (1ª ed.). San Francisco, California : No Starch Press. pag. 61 . ISBN 978-1-886411-29-6. En redes grandes como las Big Four (EFnet, IRCnet, Undernet y DALnet), intentar enumerar los miles de canales con Ircle siempre provoca que te desconectes debido a la avalancha de información, mientras que otros clientes normalmente pueden gestionar la hazaña, si están en una conexión Ethernet directa.
  27. ^ a b Jones, Steve, ed. (10 de diciembre de 2002). "Internet Relay Chat". Enciclopedia de los nuevos medios: una referencia esencial a la comunicación y la tecnología (1ª ed.). Thousand Oaks, California : Publicaciones SAGE . pag. 257 . ISBN 978-0-7619-2382-4. Hoy en día existen cientos de redes IRC independientes, pero las "Cuatro Grandes" son EFNet, UnderNet, Dalnet e IRCnet.
  28. ↑ a b Rittner, Don (3 de marzo de 1999). The iMac Book (1ª ed.). Scottsdale, Arizona : Grupo Coriolis. pag. 215. ISBN 978-1-57610-429-3. Hay varias redes grandes: EFnet, UnderNET, DALnet e IRCnet forman las Cuatro Grandes.
  29. ^ Turbante, Efraim; Leidner, Dorothy; McLean, Ephraim; Wetherbe, James (7 de febrero de 2005). "Comunicación". Tecnologías de la información para la gestión: transformación de las organizaciones en la economía digital (5ª ed.). Hoboken, Nueva Jersey : John Wiley & Sons . págs. 106-107. ISBN 978-0-471-70522-2. Las redes más grandes se han agrupado tradicionalmente como las "Cuatro Grandes": EFNet, IrcNet, QuakeNet y UnderNet.
  30. ^ "Redes IRC - Top 100" . irc.netsplit.de . netsplit.de . Consultado el 29 de octubre de 2018 .
  31. ^ "Servidores" . Protocolo de chat de retransmisión de Internet . pag. 4. seg. 1.1. doi : 10.17487 / RFC1459 . RFC 1459 .
  32. ^ "Clientes" . Chat de retransmisión de Internet: Arquitectura . pag. 3. seg. 2.2. doi : 10.17487 / RFC2810 . RFC 2810 .
  33. ^ "Clientes" . Protocolo de chat de retransmisión de Internet . pag. 5. seg. 1.2. doi : 10.17487 / RFC1459 . RFC 1459 .
  34. ^ "Números de puerto" . Marina del Rey, California : Autoridad de Números Asignados de Internet . 6 de abril de 2011 . Consultado el 5 de abril de 2021 .
  35. ^ "Mensaje de conexión" . Protocolo de chat de retransmisión de Internet . pag. 29. seg. 4.3.5. doi : 10.17487 / RFC1459 . RFC 1459 .
  36. ^ Lucas, Mark; Singh, Abhishek; Cantrell, Chris (5 de octubre de 2006). "Definición de un cortafuegos". En Henmi, Anne (ed.). Políticas de firewall y configuraciones de VPN . Rockland, Massachusetts : Syngress Publishing. pag. 93. ISBN 978-1-59749-088-7.
  37. ^ Abraham, Dalen (junio de 1998). Extensiones del Protocolo de chat de retransmisión de Internet (IRCX) . IETF . Proyecto de identificación-pfenning-irc-extensions-04 . Consultado el 8 de abril de 2011 .
  38. ^ "Arquitectura" . Chat de retransmisión de Internet: Arquitectura . págs. 3 - 4. seg. 3. doi : 10.17487 / RFC2810 . RFC 2810 .
  39. ^ "Introducción" . Chat de retransmisión de Internet: Arquitectura . pag. 2 segundos. 1. doi : 10.17487 / RFC2810 . RFC 2810 .
  40. ^ "Algoritmos" . Protocolo de chat de retransmisión de Internet . pag. 64 seg. 9.3. doi : 10.17487 / RFC1459 . RFC 1459 .
  41. ^ "Congestión de la red" . Chat de retransmisión de Internet: Arquitectura . págs. 7 - 8. seg. 6.3. doi : 10.17487 / RFC2810 . RFC 2810 .
  42. ^ "A un canal" . Chat de retransmisión de Internet: Arquitectura . págs. 5 - 6. seg. 5.2.1. doi : 10.17487 / RFC2810 . RFC 2810 .
  43. ^ "Demonios de IRC para LAN" . Consultado el 2 de octubre de 2014 .
  44. ^ "Ejecución de un servidor IRC propio" . Consultado el 2 de octubre de 2014 .
  45. ^ "Formato de mensaje en 'pseudo' BNF" . Protocolo de chat de retransmisión de Internet . pag. 8. seg. 2.3.1. doi : 10.17487 / RFC1459 . RFC 1459 .
  46. ^ "Respuestas numéricas" . Protocolo de chat de retransmisión de Internet . pag. 10. seg. 2.4. doi : 10.17487 / RFC1459 . RFC 1459 .
  47. ^ "Modos de lista de IRC: extensión del modo de lista que muestra confusión de pares para las listas" . 25 de noviembre de 2009 . Consultado el 8 de abril de 2011 .
  48. ^ a b "A un grupo (canal)" . Protocolo de chat de retransmisión de Internet . pag. 11. seg. 3.2.2. doi : 10.17487 / RFC1459 . RFC 1459 .
  49. ^ "Mensaje de lista" . Protocolo de chat de retransmisión de Internet . pag. 24 seg. 4.2.6. doi : 10.17487 / RFC1459 . RFC 1459 .
  50. ^ a b "Mensaje de ingreso" . Protocolo de chat de retransmisión de Internet . pag. 19. seg. 4.2.1. doi : 10.17487 / RFC1459 . RFC 1459 .
  51. ^ "Alcance del canal" . Chat de retransmisión de Internet: Gestión de canales . págs. 3 - 4. seg. 2.2. doi : 10.17487 / RFC2811 . RFC 2811 .
  52. ^ "Propiedades del canal" . Chat de retransmisión de Internet: Gestión de canales . pag. 4. seg. 2.3. doi : 10.17487 / RFC2811 . RFC 2811 .
  53. ^ " Duración del canal" . Chat de retransmisión de Internet: Gestión de canales . pag. 5. seg. 3. doi : 10.17487 / RFC2811 . RFC 2811 .
  54. ^ "Modos de canal" . Chat de retransmisión de Internet: Gestión de canales . pag. 7. seg. 4. doi : 10.17487 / RFC2811 . RFC 2811 .
  55. ^ "Mensaje de modo" . Protocolo de chat de retransmisión de Internet . pag. 21. seg. 4.2.3. doi : 10.17487 / RFC1459 . RFC 1459 .
  56. ^ "Modos de canal" . Protocolo de chat de retransmisión de Internet . págs. 21 - 22. seg. 4.2.3.1. doi : 10.17487 / RFC1459 . RFC 1459 .
  57. ^ "Control de acceso al canal" . Chat de retransmisión de Internet: Gestión de canales . págs. 10 - 11. seg. 4.3. doi : 10.17487 / RFC2811 . RFC 2811 .
  58. ^ a b "Respuestas de comando: 353 RPL_NAMREPLY" . Protocolo de chat de retransmisión de Internet . pag. 51. doi : 10.17487 / RFC1459 . RFC 1459 .
  59. ^ Roeckx, Kurt (14 de octubre de 2004). "El 005 numérico: ISUPPORT" . irc.org . Consultado el 10 de abril de 2011 .
  60. ^ Brocklesby, Edward (septiembre de 2002). IRC RPL_ISUPPORT Definición numérica . IETF . Proyecto de identificación-brocklesby-irc-isupport-03 . Consultado el 10 de abril de 2011 .
  61. ^ "Mensaje de Operwall" . Protocolo de chat de retransmisión de Internet . pag. 41. seg. 5.6. doi : 10.17487 / RFC1459 . RFC 1459 .
  62. ^ Carnicero, Simon (12 de enero de 2005). "Lista de modos de usuario de IRC" . alien.net.au . Consultado el 10 de abril de 2011 .
  63. ^ Carnicero, Simon (12 de enero de 2005). "Lista de modos de canal IRC" . alien.net.au . Consultado el 10 de abril de 2011 .
  64. ^ Carnicero, Simon (12 de enero de 2005). "Lista de modos del servidor IRC" . alien.net.au . Consultado el 10 de abril de 2011 .
  65. ^ Olsen, Tommy. "Modos IRCd" . webtoman.com. Archivado desde el original el 15 de octubre de 2011 . Consultado el 10 de abril de 2011 .
  66. ^ a b "Operadores" . Protocolo de chat de retransmisión de Internet . pag. 5. seg. 1.2.1. doi : 10.17487 / RFC1459 . RFC 1459 .
  67. ^ Thiedeke, Udo (23 de septiembre de 2003). "Nicola Döring, Alexander Schestag" . Virtuelle Gruppen: Charakteristika und Problemdimensionen (en alemán) (2ª ed.). Springer VS  [ de ] . págs. 314, 337. ISBN 978-3-531-33372-4. Consultado el 30 de marzo de 2010 .
  68. ^ Rogers, Russ (1 de diciembre de 2004). "La mente del terror" . En Devost, Matthew G. (ed.). Hackear una red terrorista: la amenaza silenciosa de los canales encubiertos (1ª ed.). Rockland, Massachusetts : Syngress Publishing. pag. 10. ISBN 978-1-928994-98-5. Consultado el 30 de marzo de 2010 .
  69. ^ Petersen, Julie K., ed. (29 de mayo de 2002). "Chat de retransmisión de Internet" . Diccionario ilustrado de telecomunicaciones (2ª ed.). Prensa CRC . pag. 500. ISBN 978-0-8493-1173-4. Consultado el 30 de marzo de 2010 .
  70. ^ "Preguntas frecuentes" . freenode . Archivado desde el original el 26 de marzo de 2010 . Consultado el 30 de marzo de 2010 .
  71. ^ "IRC / Cloaks" . Meta-wiki . Consultado el 27 de noviembre de 2011 .
  72. ^ "Esquemas de identificador uniforme de recursos (URI)" . Autoridad de Números Asignados de Internet . Consultado el 14 de octubre de 2012 .
  73. ^ Carnicero, Simon (enero de 2003). Esquemas uniformes de localización de recursos para entidades de chat de retransmisión por Internet . IETF . Proyecto de identificación-carnicero-irc-url-04 . Consultado el 10 de abril de 2011 .
  74. ^ "nodo-irc" . npm . Consultado el 30 de julio de 2021 .
  75. ^ "Tamaño" . Una discusión sobre conferencias en red de computadoras . págs. 5 - 6. seg. 2.5.1. doi : 10.17487 / RFC1324 . RFC 1324 .
  76. ^ "Escalabilidad" . Chat de retransmisión de Internet: Arquitectura . pag. 7. seg. 6.1. doi : 10.17487 / RFC2810 . RFC 2810 .
  77. ^ Loesch 2003 1.2.1 Crecimiento
  78. ^ "Identificación de usuario" . Una discusión sobre conferencias en red de computadoras . pag. 10. seg. 5.4.1. doi : 10.17487 / RFC1324 . RFC 1324 .
  79. ^ "Árboles y ciclos" . Una discusión sobre conferencias en red de computadoras . pag. 10. seg. 5.4.2. doi : 10.17487 / RFC1324 . RFC 1324 .
  80. ^ Loesch 2003 1.2.2 Fallos de red
  81. ^ "Problemas de información del estado" . Una discusión sobre conferencias en red de computadoras . pag. 4. seg. 2.1. doi : 10.17487 / RFC1324 . RFC 1324 .
  82. ^ Loesch 2003 1.2.3 Aspectos sociológicos y de seguridad
  83. ^ "Mensaje pasando" . Una discusión sobre conferencias en red de computadoras . pag. 7. seg. 5.2.1. doi : 10.17487 / RFC1324 . RFC 1324 .
  84. ^ "Seguridad de la conferencia" . Una discusión sobre conferencias en red de computadoras . pag. 8. seg. 5.2.4. doi : 10.17487 / RFC1324 . RFC 1324 .
  85. ^ "Obtención de ayuda en EsperNet" . La red EsperNet IRC . Consultado el 31 de julio de 2012 .
  86. ^ brandon (18 de mayo de 2010). "Nueva función: SSL para usuarios" . DALnet . Consultado el 31 de julio de 2012 .
  87. ^ Smith, Roderick W. (8 de abril de 2000). "Internet: uso de IRC para obtener ayuda" . El manual de configuración de arranque múltiple . Serie de manuales. Upper Saddle River, Nueva Jersey : Que Publishing . pag. 289 . ISBN 978-0-7897-2283-6. Consultado el 25 de julio de 2010 . mIRC es uno de los clientes IRC de Windows más populares.
  88. ^ "Wiki del navegador Opera: Cliente IRC" . Archivado desde el original el 17 de marzo de 2011 . Consultado el 10 de abril de 2011 .
  89. ^ "Wiki Warsow: Módulo IRC" . Archivado desde el original el 25 de abril de 2011 . Consultado el 10 de abril de 2011 .
  90. ^ Guenter, Daniel (21 de junio de 2004). "Revisión UT2004" . BCCHardware . Consultado el 10 de abril de 2011 .
  91. ^ "La guía de enlace ascendente definitiva" . Consultado el 10 de abril de 2011 .
  92. ^ "ZDaemon - The Doom Wiki: otras utilidades" . Consultado el 10 de abril de 2011 .
  93. ^ "Cómo configurar [sic] un cliente de IRC para conectarse e iniciar sesión [sic] en Ustream" . Ayudantes de Ustream. 29 de enero de 2012 . Consultado el 27 de abril de 2013 .
  94. ^ Mauldor (20 de junio de 2010). "Ustream contra Justin.tv" . LiquidSilver . Consultado el 13 de julio de 2011 .
  95. ^ "Twitch IRC" . Centro de ayuda de Twitch . El 7 de abril de 2017 . Consultado el 30 de octubre de 2017 .
  96. ↑ Canavan, John. "La evolución de los robots IRC maliciosos" (PDF) . www.symantec.com . Respuesta de seguridad de Symantec.
  97. ^ "Léame de psyBNC" . psybnc.at . Consultado el 10 de abril de 2011 .
  98. ^ Carey, Chris (18 de julio de 2009). "IRC con pantalla irssi-proxy +" . chriscarey.com . Consultado el 10 de abril de 2011 .
  99. ^ "Frontend desmontable (Core Rewrite) / UML / Puerto de Windows (pateando Glade)" . smuxi.org. 25 de diciembre de 2004 . Consultado el 25 de julio de 2010 .
  100. ^ "Acerca de Smuxi" . smuxi.org . Consultado el 10 de abril de 2011 .
  101. ^ Cordero, Paul (27 de julio de 2004). "Usuarios y Canales". IRC Hacks (1ª ed.). Sebastopol, California : O'Reilly Media . págs. 44–46. ISBN 978-0-596-00687-7.
  102. ^ Wang, Wallace (25 de octubre de 2004). "Mensajería instantánea y salas de chat en línea: Internet Relay Chat (IRC)" . Robar este libro de intercambio de archivos (1ª ed.). San Francisco, California : No Starch Press . págs.  65–67 . ISBN 978-1-59327-050-6.
  103. ^ Vamosi, Robert (8 de mayo de 2002). "Películas pirateadas: ahora se reproducen en un servidor cercano" . ZDNet . Consultado el 10 de abril de 2011 .
  104. ^ Sasaki, Darla (4 de abril de 2002). "IRC 101: ¿Qué es y cómo se usa?" . Macobserver.com . Consultado el 10 de abril de 2011 .

Bibliografía general

  • Reed, Darren (mayo de 1992). Una discusión sobre conferencias en red de computadoras . IETF . doi : 10.17487 / RFC1324 . RFC 1324 . Consultado el 30 de octubre de 2009 .
  • Oikarinen, Jarkko ; Reed, Darren (mayo de 1993). Protocolo de chat de retransmisión de Internet . IETF . doi : 10.17487 / RFC1459 . RFC 1459 . Consultado el 30 de octubre de 2009 .
  • Kalt, Christophe (abril de 2000). Chat de retransmisión de Internet: Arquitectura . IETF . doi : 10.17487 / RFC2810 . RFC 2810 . Consultado el 30 de octubre de 2009 .
  • Kalt, Christophe (abril de 2000). Chat de retransmisión de Internet: Gestión de canales . IETF . doi : 10.17487 / RFC2811 . RFC 2811 . Consultado el 30 de octubre de 2009 .
  • Loesch, Carl (17 de julio de 2003). "Funcionalidad que brindan los sistemas para conferencias síncronas" . psyc.eu . Consultado el 10 de abril de 2011 . Cite journal requiere |journal=( ayuda )

Otras lecturas

  • Kalt, Christophe (abril de 2000). Chat de retransmisión de Internet: Protocolo de cliente . IETF . doi : 10.17487 / RFC2812 . RFC 2812 . Consultado el 30 de octubre de 2009 .
  • Kalt, Christophe (abril de 2000). Chat de retransmisión de Internet: Protocolo de servidor . IETF . doi : 10.17487 / RFC2813 . RFC 2813 . Consultado el 30 de octubre de 2009 .
  • "Registros de los principales eventos de la comunidad online" . Chapel Hill, Carolina del Norte : ibiblio . Consultado el 8 de abril de 2011 .
  • Carnicero, Simon. "Información técnica del IRC" . alien.net.au . Consultado el 10 de abril de 2011 .

enlaces externos

  • IRC en Curlie
  • Lista de números de IRC
  • Historia del IRC
  • IRC.org - Información técnica e histórica del IRC6; Artículos sobre la historia del IRC
  • IRChelp.org - Archivo de ayuda de Internet Relay Chat (IRC); Gran archivo de documentos relacionados con el IRC
  • IRCv3 : grupo de trabajo de desarrolladores, que agregan nuevas funciones al protocolo y escriben especificaciones para ellas
  • IRC-Source : motor de búsqueda de canales y red de Internet Relay Chat (IRC) con datos históricos
  • irc.netsplit.de - Listado de redes de Internet Relay Chat (IRC) con datos históricos
Obtenido de " https://en.wikipedia.org/w/index.php?title=Internet_Relay_Chat&oldid=1039145334#Channel_operators "
Contribute a better translation