KumoIRCd

De OoKoo.org.

Sommaire 1 Status 2 Spécificités 2.1 Architecture du core 2.2 Liste des modules 2.3 Connexions inter-serveur 2.3.1 Fonctionnement du broadcast 2.3.2 Numéros de série des serveurs 2.3.3 Numéros de série des utilisateurs 2.4 Mises à jour

Status

KumoIRCd est actuellement dans la phase alpha de son développement.

SVN : http://ookoo.org/svn/kumo/

Spécificités

Architecture du core

KumoIRCd est articulé autour d'un module principal (core) qui gère la totalité des autres modules. Il n'est pas prévu de modifications au code source du core. De ce fait cette partie du code ne doit contenir que des éléments qui ne risquent pas de changer. Pour le moment, le core contient :

• Initialisation (message de bienvenue, fork, etc...)
• Lecture de la configuration (parsing)
• Chargement des modules
• Fonctions de gestion d'évenements, de hooks, de mémoire et de tables de hash
• Fonctions de gestion de structures
• Une interface vers les libs linkées (TRE, ares)
• Boucle principale

Les fonctions des addons ne seront pas accessibles d'un addon à l'autre. Seules certaines fonctions de l'exécutable principal seront fournies au module pour lui permettre de créer ses hooks et ses events.

Par exemple le module net_socket prendra le hook sur hook_main_wait (hook principal utilisé pour mettre en attente la boucle principale). Quand un utilisateur se connectera, ce module appellera un hook hook_new_user qui tombera dans le module irc_users, qui lui-même appellera un event event_new_user. Cet event aura de l'effet dans plusieurs modules (de net_dns, jusqu'à misc_proxycheck).

Liste des modules

• core (dep: none)

Système central, ceci est un module résident (ne peut être enlevé).

• net_sockets (dep: core)

Module de gestion réseau. Ce module gère pour chaque user les «SendQ», «RecvQ», etc... ainsi que les nouvelles connexions.

• irc_users (dep: net_sockets)

Ce module hook sur hook_new_user afin de recevoir les demandes de connexion et créer les structures pour les nouveaux utilisateurs.

• irc_numerics (dep: core)

Ce module fournit une sous-fonction qui permet, à partir d'un numeric, d'obtenir le message IRC correspondant.

• irc_parser (dep: irc_users, irc_numerics)

Module de «parsing» des commandes reçues des utilisateurs.

• irc_dns (dep: irc_users)

Ce module gère le «resolv» de l'adresse IP de l'utilisateur de manière asynchrone, via libares. Pendant le resolv l'utilisateur est bloqué et ne peut pas encore accéder au réseau

• misc_dnsdaemon (dep: core, net_sockets)

Module de serveur dns, utilisé pour les réseaux contenant de nombreux serveurs.

D'autres modules vont être ajoutés à cette liste dans le futur.

Connexions inter-serveur

L'architecture inter-serveur de Kumo est différente des autres serveurs IRC, et de même pour la configuration de chaque serveur “leaf“. Tout ce dont un serveur a besoin pour se connecter à un réseau est un «point d'entrée». Quand le serveur est connecté au point d'entrée, ses infos (ip, clé, etc) sont vérifiées. Soit elles sont présentes dans le cache de l'entry point, soit la demande est transmise au serveur principal du réseau.

Une fois le serveur connecté au réseau, il va devoir établir une seconde connexion sur un autre point du réseau. Par défaut un serveur essayera d'avoir toujours deux connexions à un réseau, en plus des connexions qu'il peut reçevoir d'autre serveurs.

Chaque paquet de données envoyé sur le réseau est taggué avec le numéro du serveur et un numéro de série unique. Le paquet peut avoir plusieurs types de destinations :

• Utilisateur (le paquet est routé jusqu'au serveur qui est responsable de cet utilisateur via la route la plus rapide)
• Channel (équivalent à un broadcast séléctif)
• Serveur (le paquet est routé par la route la plus rapide jusqu'au serveur indiqué)
• Serveurs (le paquet a plusieurs serveurs de destination et sera routé vers chacun de ces serveur)
• Broadcast (le paquet est simplement broadcasté à tous les serveurs)

Fonctionnement du broadcast

Lors de l'envoi d'un paquet de type broadcast, le serveur d'origine groupe les serveurs par liaison principale (le lien le plus rapide pour router vers ces serveurs) et envoie un paquet sur chacune de ses connexions avec comme destinataire les serveurs concernés.

Numéros de série des serveurs

Chaque serveur a un numéro unique sur 16 bits (entre 0 et 65535). De ce fait un réseau ne peux contenir plus de 65536 (2^16) serveurs.

Numéros de série des utilisateurs

Chaque utilisateur a un numéro de série sur 32 bits. Les 16 bits de poids fort correspondent au numéro de série du serveur, Les 16 bits de poids faible sont attribués de manière unique par le serveur en question. Il en resulte qu'un serveur ne peut pas contenir plus de 65536 (2^16) utilisateurs, et qu'un réseau est donc limité à 4294967296 (2^32) utilisateurs.

Mises à jour

Les mises à jour (hors core) doivent pouvoir se faire sans interruption du service. Le principe est relativement simple, et consiste à charger les nouveaux modules pour ensuite libérer les anciens modules.

Toutefois en cas de mise à jour des structures utilisées par les modules, on risque de rencontrer certains problèmes. Pour palier à ce problème, le core contient des fonctions de gestion des structures qui s'occupera de modifier les données en mémoire afin de correspondre aux nouvelles structures.

En cas de problème lors du chargement du nouveau module, l'ancien module reste en action et le chargement est annulé. Un message d'erreur est envoyé à l'utilisateur qui a tenté de recharger le module.

Ce type de mise à jour n'est pas réalisable sous windows à cause de la manière dont les fichiers sont traités. Un fichier en utilisation ne peut être remplacé.