IRCd

Un IRCd, o Internet Relay Chat daemon (demonio) es un software que permite crear
una red donde la gente puede conectarse para mantener conversaciones en tiempo real
en la red mediante el protocolo IRC.

Índice
1 Funcionamiento general de una red de IRC
2 Servicios del IRC
3 Control distribuido de la red de IRC
4 Otras mejoras reseñables
5 Instalación y configuración del IRCd
6 Enlaces externos
6.1 Información general
Funcionamiento general de una red de IRC
Una red de IRC está compuesta por uno o más nodos de acceso cada uno de los cuales
ejecuta un IRCd compatible con el resto, que en general suele ser el mismo para
todos los nodos (no necesariamente la misma versión) pero en el caso de algunas
redes no todos los nodos ejecutan el mismo IRCd sino diferentes implementaciones
cuyos protocolos sean compatibles. El protocolo IRC básico está descrito en el RFC
1459 no obstante con el tiempo han ido surgiendo otros RFC como el RFC 2810, RFC
2811, RFC 2812 y RFC 2813 junto con otras modificaciones propias de cada rama (la
mayoría de IRCd's en producción en la actualidad descienden de una base de código
común, a base de forks del IRCd original y sus descendientes). Esto no es demasiado
importante puesto que como hemos apuntado por lo general todos los nodos de una
misma red de IRC utilizan versiones de una misma implementación del software
servidor, siendo la interfaz cliente-servidor la más delicada puesto que a ninguna
red de IRC le interesa hacer su software servidor incompatible con los clientes de
IRC existentes en el mercado, los programas que permiten a los usuarios conectarse
a la red y hacer uso de sus servicios.

Por lo general los servidores de IRC tienen habilitada una serie de clases de
conexión para clientes y servidores indicando cada una de ellas parámetros como el
máximo de usuarios, puerto de conexión, opciones de enlace en el caso de
servidores, etc. En la conexión entre dos servidores de IRC uno actúa como hub y el
otro como leaf, se dice que el primero es el Uplink del segundo, su enlace con el
resto de la red. En la interconexión de los nodos de una red de IRC no hay
redundancia y por este motivo es posible (y frecuente en el caso de algunas redes)
experimentar el fenómeno de los netsplits, separaciones temporales entre los nodos
de la red por fallos de conexión o caída de alguno de los nodos que la confrman,
resultando esto a la vista de los usuarios en la desaparición repentina y en bloque
de todos los usuarios conectados a uno de los servidores que se encuentran en la
parte de red de la que ha sido desconectado aquel que les da servicio. En los
últimos tiempos una causa bastante frecuente de este tipo de problemas han sido los
ataques de denegación de servicio sufridos por alguno o varios de los nodos de la
red precisamente con el objetivo de molestar a sus usuarios y crearle mala fama a
la red en cuestión. Cuando dos servidores se conectan por primera vez o reconectan
tras un netsplit, se desarrolla el proceso conocido como netburst (en la
terminología de algunas implementaciones) o netjoin (término más genérico) que
consiste en la sincronización de la información del estado de la red en cada lado.
Cada nodo informa al otro de los canales y usuarios existentes en la parte de la
red que representa así como los usuarios presentes en cada canal, la configuración
de cada uno de estos últimos, etc. Este proceso no está exento de problemas y en
muchos casos, especialmente en redes medianamente grandes, se dan conflictos entre
las dos partes de la red: usuarios duplicados, canales con el mismo nombre y
diferentes configuraciones, operadores, etc. Estas desincronizaciones pueden
resolverse con diferentes criterios en función del IRCd que estemos utilizando,
generalmente atendiendo a fechas (prioridad al más antiguo o nuevo) y jerarquía de
la red (prioridad a lo que diga el hub). Existe la posibilidad de proporcionar a
algunos nodos de la red privilegios especiales para hacer prevalecer sus órdenes
sobre las del resto, por lo general asignadas a nodos de servicios que veremos con
más detenimiento posteriormente.

Una vez establecida la conexión estando el IRCd en pleno funcionamiento la mecánica

básica consiste en recibir los comandos provenientes de los usuarios y servidores
con los que está directamente conectado y procesarlos o propagarlos a su destino
final en función de su objetivo, que puede ser el propio servidor, otro servidor,
un grupo de servidores especificado por una máscara, un usuario local, un usuario
remoto o un canal. De este modo se mantiene la comunicación entre usuarios
conectados en diferentes servidores de la red aunque tampoco este mecanismo de
propagación está libre de problemas puesto que al no ser la comunicación
instantánea, a causa de los diferentes retardos que pudieran existir entre los
diferentes nodos de la red es posible que cuando el mensaje llegue a su destino el
usuario haya cambiado de nombre, por ejemplo. Este problema está parcialmente
subsanado en algunas implementaciones mediante la aplicación de alguna de las
mejoras del protocolo original que veremos más adelante.

Servicios del IRC

Con el tiempo las administraciones de las redes de IRC se dieron cuenta de que la
funcionalidad original provista por el protocolo IRC era algo limitada. Por
ejemplo, el primer usuario en entrar en un canal es designado automáticamente
operador de dicho canal y para mantener este privilegio ha de permanecer conectado
a la red y dentro del canal en cuestión o bien designar otros operadores que puedan
restaurar su estado de operador más adelante. Por otra parte, el nick (alias) de un
usuario puede ser establecido siempre y cuando sea válido y esté libre, de modo que
un usuario puede encontrarse al conectarse a la red que su nick habitual está
opcupado por otro usuario que puede además intentar suplantarle.

Algunos de estos problemas podían ser inicialmente resueltos por los operadores del
IRC (IRCops), usuarios con unos privilegios especiales definidos en la
configuración del servidor que les permiten hacer cosas como expulsar a un usuario
de la red o conceder privilegios de operador en un canal a cualquier usuario sin la
necesidad de tener dicho estatus en el canal con anterioridad. No obstante a medida
que las redes crecieron esto se tornó claramente ineficiente.

La primera solución a este problema fue la creación de bots (robots del IRC),
programas que conectaban como cliente a la red de IRC y, con privilegios de
operador y una interfaz en forma de línea de comandos mediante mensajes privados,
podían automatizar algunas de estas tareas, por ejemplo permitir el registro de
apodos y canales por contraseña y encargarse de autenticar a los usuarios para
posteriormente restituirles los privilegios o forzarlos a cambiarse de apodo en
caso de no poder demostrar ser los dueños legítimos del mismo.

No obstante esta solución no es del todo eficiente puesto que la implementación en

modo cliente hace difícil que el programa robot disponga de toda la información
necesaria y generalmente la calidad del enlace con la red es insuficiente, vemos
que por ejemplo si queremos que el bot monitorice la actividad de todos los canales
debería de estar dentro de todos ellos (algunos IRCd tienen un límite duro en
cuanto al máximo de canales en los que puede estar un usuario simultáneamente, en
otros casos esto es configurable), lo cual no parece muy adecuado.

La solución a esto son los nodos de servicios. Un nodo de servicios es un tipo

especial de IRCd que por lo general no acepta conexiones de clientes ni servidores
y únicamente puede ser conectado a un hub. De cara al resto de la red se comporta
como uno más, haciendo ver al resto de la red que tiene conectados a él una serie
de clientes que no son tales conocidos como pseudoclientes. Estos pseudoclientes
actúan a modo de interfaz con los usuarios permitiendo la clásica interacción en
forma de línea de comandos, pero el receptor último de los comandos enviados es el
propio nodo de servicios que ahora aprovecha todas las facilidades derivadas de su
condición de servidor. Los nodos de servicios por lo general disponen además de
comandos especiales restringidos al protocolo servidor-servidor permitiéndoles
acciones como el renombrado de usuarios, desconexión de otros servidores, etc.
Habitualmente algunos de estos comandos requieren una autorización especial como se
ha mencionado anteriormente, que permite al resto de nodos de la red identificar al
nodo de servicios como tal.

Las funciones más habituales de los nodos de servicios se refieren al registro de

usuarios para preservar el uso de su nick, registro de canales, mensajería entre
usuarios (una especie de buzón personal para recibir mensajes cuando un usuario no
está conectado) y servicios de apoyo a la administración de la red. Otros paquetes
de servicios poseen además funcionalidades estadísticas, permitiendo generar
informes de uso de la red tales como gráficas representando la fluctuación del
número de usuarios y canales en activo a lo largo del tiempo, así como servicios de
valor añadido para los usuarios como enlaces con webservices desde un bot de la red
de IRC. Otra de las funciones habitualmente llevadas a cabo por los nodos de
control es la de prevención de ataques, analizando las conexiones entrantes para
intentar decidir si se tratan de conexiones a través de proxies anónimos o
similares, (uno de los ataques más típicos en redes de IRC son los ataques de
clones).

No obstante este modelo de red presenta una debilidad importante, el problema de la

centralización. Al estar los servicios localizados en un nodo (el nodo de
servicios), una caída de dicho nodo o un netsplit dejaría al menos una parte de la
red fuera del alcance del nodo de control, con lo que se puede decir que la red
tiene en el nodo de servicios su punto débil. Ante un netsplit usuarios
malintencionados podrían aprovecharse de la ausencia de los servicios de red para
suplantar a otro usuario o tomar el control de un canal ajeno. Existe una solución
a este problema basada en el control distribuido.

Control distribuido de la red de IRC

Para solucionar el problema de la centralización mencionado y de paso ofrecer a la
larga algunos servicios de valor añadido a sus usuarios, la extinta red española
ESNET ideó un nuevo mecanismo de gestión de la red de IRC. El nuevo sistema
consistía en que cada uno de los nodos de la red dispusiera de su propia copia
local de una base de datos distribuida (BDD), similar a la base de datos de los
servicios de red pero limitada a la información esencial para el funcionamiento
básico de la red.

Inicialmente se empezó almacenando la información de los usuarios, apodo y

contraseña. De este modo los usuarios podían autenticarse directamente con el nodo
al que se conectaban sin la intervención de un nodo de servicios y con
independencia de que la red estuviese en netsplit. Así se evitaba el problema de
que un usuario pudiese suplantar a otro durante un netsplit o mientras los
servicios de red se encontrasen fuera de servicio. Pronto se fueron encontrando
otros usos para la base de datos distribuida, que se organizaba en una serie de
tablas con la estructura más simple posible, dos campos, clave y valor (cadenas
ambos). Naturalmente este proceso tampoco se libra de problemas de sincronización y
fue necesario desarrollar un protocolo conocido como protocolo DB para asegurar que
durante la operación normal de la red y en los netburst la información de la base
de datos distribuida se mantuviese consistente entre los diferentes nodos.

Aunque en un principio la información de la base de datos era manipulada

directamente por los administradores de la red ESNET, pronto se vio este sistema
como un complemento para el modelo tradicional del nodo central de control. El nodo
de control podía actuar de la manera habitual atendiendo las peticiones de registro
y configuración de los usuarios para posteriormente registrar los cambios
relevantes en la base de datos distribuida haciendo uso de sus privilegios
especiales. Algunas de sus antiguas funciones como la autenticación de usuarios ya
no eran necesarias puesto que cada nodo local se encargaría de realizarlas, de este
modo los servicios de red aún eran necesarios para dar usuarios de alta o realizar
modificaciones pero los servicios mínimos de la red se mantenían en caso de haber
problemas. El protocolo DB evolucionó para convertirse en DBH, y se sucedieron
varias versiones del mismo.

Otras mejoras reseñables

Aparte de la incorporación de la base de datos distribuida en el IRCd de ESNET, las
diferentes variantes del IRCd original han ido incorporando diferentes mejoras al
protocolo original, entre las cuales destacamos:

Compresión de enlaces: Compresión del tráfico entre servidores para lograr una
mayor velocidad de transmisión sacrificando tiempo de CPU (empleado en la
compresión y descompresión de la información).
Enlaces seguros: Empleo de técnicas como SSL para proteger la comunicación entre
servidores y/o con los clientes de filtraciones indeseadas. Lamentablemente, ésta
opción parece no ser muy eficaz en cuanto a seguridad.
Nuevos modos de canal y usuario: En suma a los modos provistos en el IRC estándar
algunos IRCds definen nuevos modos de usuario y canal para ofrecer una mayor
funcionalidad a los usuarios: restricción de mensajes privados, de colores enviados
a los canales, control de ataques, etc. Conviene encontrar un compromiso entre
funcionalidad y eficiencia puesto que algunas posibilidades que pueden resultar
divertidas en realidad tienen escasa utilidad real y se traducen en una bajada de
rendimiento del IRCd, si bien en función del tamaño de la red nos podemos utilizar
un IRCd más o menos cargado de características adicionales.
Hosts virtuales: El IRC original permite que un usuario pueda conocer la dirección
IP de sus interlocutores y esto se ha traducido durante años en un problema de
seguridad para los participantes de la red de IRC dado que en cualquier momento a
raíz de una disputa generada en la red uno podía ser el objetivo de ataques de
denegación de servicio y similares con el objetivo de desconectar al usuario en
cuestión de la red por la fuerza o simplemente para fastidiar. La mayoría de IRCds
modernos utilizados en las principales redes de IRC permiten al usuario definir un
modo por el cual su dirección IP es sustituida por un nombre de host virtual
generalmente resultado de la codificación de su host real de forma que sólo los
administradores de la red puedan revertir el proceso. Algunos IRCds permiten además
la definición de hosts virtuales personalizados que los usuarios pueden definir a
placer como un servicio añadido.
Tokenización del protocolo: El protocolo IRC inicial utiliza como identificadores
de comando cadenas generalmente autodescriptivas como PRIVMSG o NOTICE que sin
embargo resultan ser ineficientes llegando en algunos casos a ocupar más que el
propio mensaje a transmitir. Con el fin de minimizar el tráfico y mejorar así la
eficiencia del sistema algunos protocolos mejorados permiten además el uso de
identificadores (tokens) equivalentes con la mínima longitud posible.
Uso de numéricos: Para evitar el problema anteriormente mencionado ocasionado por
los retardos cuando un usuario cambia de nick mientras un mensaje para él está en
camino y situaciones similares, algunos IRCd asignan a servidores y clientes un
identificador único (numérico) oculto al usuario y persistente durante el tiempo
que se prolongue la conexión que será utilizado internamente para direccionarlos
con independencia del apodo del usuario o nombre del servidor en un momento dado.
Adicionalmente los numéricos permiten ahorrar caracteres puesto que por lo general
suelen tener una longitud de 2 o 3 caracteres frente a los 32 que puede llegar a
tener un apodo.
Nuevos comandos: Comandos que aportan funcionalidad adicional como SETNAME o
permiten realizar tareas con mayor eficiencia como WATCH (notificación automática
de entrada y salida de usuarios en oposición al polling con ISON).
Instalación y configuración del IRCd
En la mayoría de los casos, un IRCd será instalado en un servidor con el fin de
federarse con alguna red de IRC ya existente. En estos casos la administración de
la red en cuestión proveerá al futuro administrador del servidor con el software a
instalar y la configuración a utilizar para la correcta interconexión del nuevo
nodo con el resto de la red. Esta operación con frecuencia requerirá también
especificar una autorización de conexión para el nuevo nodo en alguno de los hubs
de la red.

En el caso de que nos propongamos iniciar una nueva red o montar un servidor de IRC
independiente deberemos hacernos primero con algún software IRCd y posteriormente
configurarlo por nuestra cuenta. Como se ha comentado con anterioridad la mayoría
de IRCd's en el mercado son derivados del original de Jarkko Oikarinen y
habitualmente están liberados bajo la GPL. Generalmente funcionan bajo entornos
Unix y compatibles, como Linux o FreeBSD, aunque existen algunos IRCds con versión
para Windows (e incluso algunos exclusivos para este entorno, no obstante no muy
populares) y otros sistemas operativos. La mayoría de estos IRCds, al menos los
principales y más conocidos, han sido desarrollados en el seno de alguna red de IRC
que tomó una versión anterior y llegado un punto decidió hacer un fork para
realizar cambios sustanciales en el protocolo para adaptarlo a sus necesidades.
Destacamos el Bahamut de DALnet, el ircU de Undernet, el Hybrid de EFnet, el IRCd
original desarrollado por IRCnet y el UnrealIRCd, un IRCd que si bien su desarrollo
no está asociado a ninguna red de importancia es muy popular en redes de tamaño
medio por la gran cantidad de características que posee en forma de modos de canal
y usuario, comandos, etc. También existen IRCds comerciales que sin embargo no han
tenido gran calado debido a su escasa calidad en comparación con los anteriormente
mencionados, en esta categoría habría que destacar Conference Room.

Una vez elegido y descargado el IRCd a utilizar, en muchos casos tendremos que
seguir el procedimiento habitual de compilación e instalación de los entornos *nix
y, en cualquier caso, una vez instalado el IRCd deberemos configurarlo. Cada IRCd
viene acompañado de una documentación que explica el contenido del fichero de
configuración y aunque existen diferencias entre las distintas implementaciones por
lo general la información básica que se ha de proporcionar es el nombre del
servidor y del administrador, las IPs y puertos de escucha, las clases de conexión,
las autorizaciones de conexión para servidores entrantes y las direcciones de los
servidores a los que nos hemos de conectar como Leaf. Opcionalmente se pueden
definir nodos y usuarios privilegiados (IRCops), exclusiones, etc. Tradicionalmente
los ficheros de configuración de los IRCds se organizaban en líneas identificadas
por una letra indicando el tipo de opción a definir, seguida por los distintos
valores separados por dos puntos según el formato de cada línea. De ahí la
denominación de G-lines (exclusiones), O-lines (IRCops), etc. para algunos
elementos en el IRC. No obstante muchos IRCd modernos han evolucionado persentando
ficheros de configuración en formatos más amigables basados en Bison o XML. Algunos
incluso admiten ciertas configuraciones globales de la red a través de una tabla a
tal efecto en la base de datos distribuida, en caso de disponer de ella.

Una manera usual de correr un servidor de IRC cuando no se dispone de una máquina
es contratar una cuenta de Shell con algún ISP. Conviene fijarse en las condiciones
puesto que muchos prohíben explícitamente el tráfico IRC. Otros ofrecen paquetes
específicamente destinados a tal uso. Un factor importante a tener en cuenta es el
número de usuarios locales que podemos atender simultáneamente, aunque esto no sólo
dependerá de las limitaciones impuestas en la máquina sino de la calidad del
enlace.

Enlaces externos
Información general
Información y recursos sobre el IRC
Control de autoridades
Proyectos WikimediaWd Datos: Q55541
Categorías: IRCProtocolos de InternetProtocolos de nivel de aplicación
Menú de navegación
No has accedido
Discusión
Contribuciones
Crear una cuenta
Acceder
ArtículoDiscusión
LeerEditarVer historial
Buscar en Wikipedia
Portada
Portal de la comunidad
Actualidad
Cambios recientes
Páginas nuevas
Página aleatoria
Ayuda
Donaciones
Notificar un error
Herramientas
Lo que enlaza aquí
Cambios en enlazadas
Subir archivo
Páginas especiales
Enlace permanente
Información de la página
Citar esta página
Elemento de Wikidata
Imprimir/exportar
Crear un libro
Descargar como PDF
Versión para imprimir

En otros idiomas
Deutsch
English
Français
Italiano
日本語
Русский
Svenska
3 más
Editar enlaces
Esta página se editó por última vez el 12 jul 2022 a las 09:15.
El texto está disponible bajo la Licencia Creative Commons Atribución Compartir
Igual 3.0; pueden aplicarse cláusulas adicionales. Al usar este sitio, usted acepta
nuestros términos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de la Fundación Wikimedia, Inc., una
organización sin ánimo de lucro.
Política de privacidadAcerca de WikipediaLimitación de responsabilidadVersión para
móvilesDesarrolladoresEstadísticasDeclaración de cookiesWikimedia FoundationPowered
by MediaWiki