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.
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.