IRC Hack tutorial
Texte par bLuReD75

Salut les loubards de l'IRC. Vous vous souvenez de l'irc-hack tutorial?
En voici la suite, avec cette fois ci des exemples en annexe (fournis 
dans le package). 


Théorie des IRC Nets	
--------------------


Clients et serveurs

IRC est un système client/serveur. Cela veut tout simplement dire qu'il 
y a une machine qui va se charger de recevoir toutes les connexions des 
clients. Les serveurs gèrent entre 10 et 1000 connexions IRC simultanées 

Les clients

Les clients, c'est vous et moi, chacun avec une machine différente. Il 
existe une multitude de clients différents, pour tous les goûts, pour 
tous les OS. La seule restriction pour pouvoir se connecter à un serveur
IRC, c'est que le client respecte le protocole défini dans le RFC 1459 
(voir fichier annexe). Les clients les plus connus sont mIRC 
sous Windows et ircII sous UNIX. 

Les serveurs

Les serveurs sont presque tous sous UNIX. Le logiciel qui s'occupe de 
recevoir et de gérer les connexions des clients s'appelle ircd (IRC 
Daemon). Les ressources exigée par un serveur dépendent essentiellement 
du nombre de personnes qui sont connectées. N'importe qui peut installer 
un serveur IRC chez lui. Par contre, pour faire partie d'un des quatre 
grands IRC Nets (20.000 personnes et plus), il faut une machine assez 
puissante, et surtout une connexion à l'Internet permanente et rapide ! 

IRC Net

Si tout le monde devait se connecter sur le même serveur, le pauvre 
serveur serait vite depassé par la situtation. C'est pourquoi en plus 
des connexions client-serveur, le protocole d'IRC permet des connexions 
serveur-serveur. 

On peut voir comment sont interconnectés les serveurs en tapant la 
commande /links.

Note : il ne doit jamais y avoir de boucle ! Heureusement, ircd vérifie 
a chaque connexion si cela ne peut pas créer de boucle. Le cas echeant, 
la connexion est annulée automatiquement. 

Comment ça marche ?

Imaginons que tous les clients representés soient sur #toto. Si le 
client 1 dit "glop" sur #toto, le serveur 7 va envoyer ce message au 
client 2, car il est aussi sur le channel #toto. Mais il va aussi 
signaler au serveur 2 que le client 1 a dit "glop" sur #toto. Le serveur
2 n'a aucun client sur #toto, donc il va seulement propager le message 
au serveur 1. Le serveur 1 enverra le message au client 3, ainsi qu'aux 
serveur 3, 4 et 8, et ainsi de suite... 

Ca veut bien dire que lorsqu'on fait "glop" sur un channel, le message
va se propager à travers le monde jusqu'aux serveurs où sont connectés
chacun des membres du channel. Par contre, le message ne se propage 
pas vers les serveurs qui ne sont pas concernés. 

La répartition en réseau de serveurs permet donc de diminuer le nombre
de connexions sur chaque serveur, mais ça ne diminue pas beaucoup le 
trafic qui passe entre les serveurs. C'est pourquoi, techniquement, on 
ne peut pas dépasser des réseaux de plus de 35.000 utilisateurs sans 
générer un lag pénible pour les utilisateurs : les connexions Internet 
sont trop lentes ! 

Netsplits

Un phénomène qui en intrigue plus d'un, c'est les splits et les joins. 
Il arrive parfois que les serveurs IRC soient surchargés, s'il y a trop 
de monde sur l'IRC Net par exemple. Lorsqu'un serveur n'arrive plus à 
suivre, il peut décider de "splitter", c'est à dire de casser une de ses
liaisons avec un autre serveur. L'IRC Net originel se retrouve alors 
scindé en deux IRC Nets complètement indépendants.

Sur un channel, on voit parfois plusieurs personnes partir au même 
moment. Cela peut être dû à un netsplit. On reste alors seul avec les 
personnes qui sont du même côté du split. Imaginons par exemple, que le
Serveur 1 et le Serveur 4 splittent. Les clients 1, 2 et 3 voient 
alors les client 4 et 5 partir, et vice-versa ! 
On peut aller voir ce qui se passe de l'autre côté du split se 
connectant à un des serveurs qui a splitté. Sur les nouveaux serveurs 
2.9, on peut voir les netsplits/netjoins simplement allant sur le 
channel &servers. Il est possible de profiter des netsplits pour gagner 
l'op sur un channel. Evidemment, ce genre de pratique peut conduire à 
de graves ennuis avec les propriétaires du channel et les IRCOPs qui 
surveillent ce genre de choses. Voyons point par point comment cela 
se passe. 

Supposons que le channel appartienne a Client 2. Jusque là tout va bien. 
Les choses se gâtent quand le Serveur A décide de splitter. 
En effet, Client 1 se retrouve alors tout seul. Il peut quitter puis 
revenir sur le channel pour devenir op. 
Au moment du netjoin, Client 2 va voir Client 1 arriver, et se faire 
oper par Serveur A. Inversement, Client 1 va voir Client 2 se faire 
oper par Serveur B. C'est ce qu'on appelle un server-op. 

Et qu'est-ce qu'on fait maintenant ? Et bien c'est le plus rapide qui 
va déoper l'autre. Mais s'ils se déopent en même temps, on peut aboutir 
à une désynchronisation ! 

Pour être sûr de gagner l'op, Client 1 aurait pu lancer un deuxième 
client sur son Serveur A qui aurait pris le même nick que Client 2. 

Au moment du netjoin, il se serait produit une "nick collision", et 
les deux personnes, Client 2 et son jumeau, auraient été déconnectées. 
Client 1 se serait retrouvé seul avec l'op.

Avec la version 2.9 des serveurs IRC intervient le Nick Delay, ND. Les 
serveurs se "souviennent" des channels et des nicks. Si l'on prend un 
nick qui existait sur un autre serveur, ou si on join un channel qui 
n'était pas vide avant le split, le serveur renvoie l'erreur : 
"Nick/channel is temporarily unavailable". Mais comme le dit le 
message, ça n'est que temporaire, et si le split dure, le channel 
pourra quand même se faire hacker. Le ND dure en général 10 à 30 
minutes, ce qui est supérieur à la durée de la plupart des splits.

Désynchronisation

Chaque serveur stocke l'état complet du réseau IRC : qui est où, sur 
quel channel, sur quel serveur, avec quels modes etc... L'état interne 
est le même à tout instant sur tous les serveurs... en théorie. En 
pratique, il y a du lag, des délais de plusieurs secondes dûs à la 
lenteur des connexions Internet. 

Cela crée un retard dans la propagation des évènements. De ce fait, 
il arrive parfois que des évènements ne se produisent pas dans le 
même ordre selon point d'où on les observe. Ca vous rappelle la 
mécanique quantique ? Alors prenons un exemple concret : 

Le client 1 deop le client 2, et au même instant (disons à un 
dixième de seconde près), le client 2 deop le client 1. 
Sur le serveur A, le deop du client 1 arrive avant le deop du 
client 2. Pour A, 2 est deopé par 1. D'autre part, sur le serveur B, 
le deop du client 1 arrive après celui du client 2. Pour B, 1 est 
deopé par 2. 
Puis, comme pour tout message, chaque serveur propage le message 
de deop qu'il a reçu à ses voisins... 
 
Mais dans notre cas, quand le deop du client 1 arrive sur le 
serveur B, 1 n'est plus op, donc le serveur B signale gentiment 
l'erreur au client 1 : "You are not channel operator". Inversement, 
le deop du client 2 ne prendra pas effet sur le serveur A. 
 
Nos deux serveurs sont maintenant dans deux états différents, et 
vont le rester ! En effet, il y a égalité entre les serveurs, donc 
il n'y a pas de raison que l'un d'eux l'emporte sur l'autre. 

Server-op

Il ya deux façon de devenir op sur un channel : 
Se faire oper par un utilisateur op 
Se faire oper par un serveur 
Pour se faire oper par un utilisateur, il faut demander au Monsieur. 
Se faire oper par un serveur, c'est simple comme bonjour : il suffit 
de joiner un channel vide ! Eh oui, lorsqu'on arrive sur un channel 
vide, c'est le serveur sur lequel on est connecté qui nous op. 
Sympa non ? 

Maintenant, voyons comment on peut utiliser notre désynch' pour 
se faire oper : 

D'abord, on kick le client 2. 
Evidemment, comme client 1 n'est pas op sur le serveur B, le 
client 2 ne va s'apercevoir de rien. Pour lui on a l'air bien sage. 
Maintenant, on quitte notre channel. Pour le serveur A, le channel
n'existe plus. 
Puis on revient ! 
Qu'est-ce qui se passe ? Et bien pour le serveur A, on vient d'entrer 
sur un channel vide, donc il nous op. Et en bon serveur qu'il est, il 
informe les autres serveurs qu'il nous a opé sur ce channel. Sur le 
serveur B, le client 2 voit de ses yeux ébahis le serveur A nous oper :-) 

Avertissement

Cette méthode peut très bien fonctionner pour prendre le pouvoir 
sur un channel. Sachez que les IRCOPs ont des moyens de surveiller 
les désynch', notamment en allant sur le canal local &channel (tout 
le monde peut y aller). Créer volontairement des désynch' est un très 
bon motif pour se retrouver banni des serveurs IRC. 

Logs

Si vous n'avez pas cru un mot de ce que j'ai raconté, voici un petit 
log. Mechant et Gentil sont sur deux serveur differents, et sont au 
depart tous les deux ops (suite a un netjoin par exemple). 

*** Users on #Glop: @Mechant @Gentil  
*** Mode change "-o Gentil" on channel #Glop by Mechant  
*** Gentil has been kicked off channel #glop by Mechant (Mechant)  
*** Users on #Glop : @Mechant  
*** Mechant has left channel #Glop (Mechant)  
*** Mechant (blured75@ted.via.ecp.fr) has joined channel #Glop +o  
*** Users on #Glop: @Mechant	

*** Users on #Glop: @Mechant @Gentil 
*** Mode change "-o Mechant" on channel #Glop by Gentil 
*** Users on #Glop : @Gentil Mechant 
*** Mechant has left channel #Glop (Mechant) 
*** Mechant (blured75@ted.via.ecp.fr) has joined channel #Glop +o 
*** Users on #Glop : @Mechant @Gentil

Après la désynch', Mechant peut quitter et joiner le channel autant 
de fois qu'il veut se faire oper par le serveur sur lequel il est. 
Ce server-op apparait ici au niveau du "+o" qui figure en fin de 
la ligne de join de Mechant : 

*** Mechant (blured75@ted.via.ecp.fr) has joined channel #Glop +o . 

Cela peut aussi apparaître sous la forme d'un 

*** Mode change "+o Mechant" on channel #Glop by irc.glop.fr 

juste après le join sur les anciennes version de serveur. 
Essayez par vous même !

Les serveurs fred.via.ecp.fr et ted.via.ecp.fr sont à votre 
disposition pour toutes les expériences possibles; ils font partie 
d'un réseau expérimental, l'ECPnet. Par contre, n'essayez pas sur 
des serveurs officiels, vous risqueriez d'en être banni. 

************************************************************************

IRC-Nets

Voici une petite liste de serveurs sur lesquels on peut se connecter 
depuis la France. Vous trouverez une liste et des cartes complètes 
de serveurs sur le site de #IRChelp . 

Principaux serveurs

IRCnet 

130 serveurs, 25.000 utilisateurs 
sil.polytechnique.fr 
irc.enst.fr 
irc.emn.fr 
irc.grolier.net 
salambo.Enserb.U-Bordeaux.Fr 
irc.insat.com 
IRC.Eurecom.FR 
irc.funet.fi 
irc.stealth.net 
irc.webbernet.net 

EFnet 

70 serveurs, 40.000 utilisateurs 
irc.ec-lille.fr 

Ce serveur français, normalement connecté à IRCnet, s'est exilé sur 
EFnet suite à de sombres histoires d'IRCOP...

Undernet 

40 serveurs, 25.000 utilisateurs 
Caen.Fr.Eu.UnderNet.org 
Diemen.NL.EU.undernet.org 

DALnet 

30 serveurs, 20.000 utilisateurs 
taxi.ny.us.DAL.net 
Serveurs divers

ECPnet 

Petit réseau deviendra... petit. 
tibob.via.ecp.fr 
LinuxNET et LISC 

Pour parler de Linux. 

irc.blackdown.org 
irc.debian.org 
Microsoft Network 
Ou les RFCs bafoués en tous points. 
irc.msn.com 

SandNET 

Un réseau sympa avec services de registration 
stlouis-mo-sandnet.ml.org 

UltraNET 

Le réseau de Club-Internet 
neuilly.fr.eu.ultranet.org 

Gamma Force 

Petit réseau Nord Americain 
phantom.ultranet.ca 

Spririt Web 

Serveur en mal de connectés 
irc.spiritweb.org 

KidLink et Kids World 
Dédié aux enfants, il faut d'abord s'inscrire.

************************************************************************

BOT	

Introduction

Je vous propose de construire étape par étape, de manière simple, un 
robot IRC. 

Connexion à une machine

Connexion

D'abord votre bot va devoir se connecter à un serveur. Vous trouverez 
ici (voir fichier annexe - prog_irc.txt) un petit programme en Python 
qui ouvre une socket en TCP sur le port 6667, exactement comme le ferait 
un client IRC "normal". Voici la version en C, (idem) un moins parlante. 
Vous pouvez aussi établir cette connexion "à la main" en tapant 
simplement sous UNIX :

telnet <server> 6667 

Par exemple : 

ted:~>telnet irc.funradio.fr 6667 

Trying 138.195.128.128... 
Connected to tibob.via.ecp.fr. 
Escape character is '^]'. 

Sous Windows, il suffit de faire "connexion distante", et préciser, en 
plus de l'hôte, le port "6667" au lieu du port "telnet". 
Maintenant, on est connecté, mais on n'est pas encore authentifié au 
niveau du serveur IRC. 

Login

Le Login est une phase ou le client donne les infos nécessaires pour 
que le serveur nous "enregistre". Le protocole est une fois de plus 
défini dans le RFC 1459 (idem voir fichier annexe) au paragraphe 4.1, 
et se résume à peu pres à : 

envoyer une première ligne : NICK <nick> 
envoyer une seconde ligne  : USER <username> <hostname>
				<servername> <realname> 
<username> est le login 
<hostname> le nom de machine 
<servername> est le nom de serveur 
<realname> est l'IRCNAME qui apparait lors d'un whois 

Remarques : 

N'oubliez pas le [enter] en fin de ligne ('\n' en C) 
hostname et servername sont ignorés par le serveur (ca ne sert que 
lorsque deux serveurs discutent entre eux) 
username sera remplacé par le vrai login si la machine depuis laquelle 
on se connecte a un démon d'identification (identd). C'est le cas de 
la plupart des machines. 

Certains serveurs demandent un mot de passe, qui doit etre specifié 
dans une troisième ligne : PASS <password> 

Certains serveurs vont envoyer un PING :<numéro>, auquel cas on 
devra répondre avec un PONG <numéro> pour terminer l'enregistrement. 

Voyons cela en pratique : 

ted:~>telnet irc.funradio.fr 6667 

Trying 138.195.128.128... 
Connected to tibob.via.ecp.fr. 
Escape character is '^]'. 
USER toto titi tata tutu 
NICK toutou 
:tibob.via.ecp.fr 001 toutou :Welcome to the Internet Relay Network 
			      toutou!fred@ted.via.ecp.fr
 
:tibob.via.ecp.fr 002 toutou :Your host is tibob.via.ecp.fr, 
			      running version 2.9.4 

:tibob.via.ecp.fr 003 toutou :This server was created Tue Feb 24 1998 
			      at 19:32:22 CET 

:tibob.via.ecp.fr 004 toutou tibob.via.ecp.fr 2.9.4 oirw abiklmnopqstv 

La plupart des clients exécutent alors immédiatement les deux 
commandes suivantes :

LUSER (vous affiche des infos sur les connexions de ce serveur) 
MOTD (vous affiche le "Message Of The Day") 

Une fonction qui effectue le LOGIN est très simple; en voici un 
exemple en Python et en C (voir annexe). 

On a maintenant un robot capable de faire de l'IRC, c'est déjà beaucoup ! 

PING ? PONG !

Malheureusement, l'espérance de vie de notre robot est, à cet instant,
limitée à quelques minutes seulement. En effet, si l'on poursuit 
notre "TP", on voit apparaître au bout d'un instant :

PING :tibob.via.ecp.fr 
ERROR :Closing Link: toutou[fred@ted.via.ecp.fr] (Ping timeout) 
Connection closed by foreign host. 

Le serveur nous envoie un PING pour vérifier que la connexion est 
bonne. Il faut répondre... PONG bien sûr ! C'est ce qu'on appelle 
"le challenge" du serveur. (voir annexe)

PING après le PONG :

PING :tibob.via.ecp.fr 
PONG :tibob.via.ecp.fr 

S'il n'y a pas de PONG, le serveur envoie un message d'erreur et 
ferme la connexion. Le délai pour répondre est de l'ordre d'une 
minute, selon les serveurs, mais on a tout intérêt à répondre le 
plus tôt possible !

Voici une fonction en Python ou en C qui écoute sur la socket
que l'on a ouvert, et repond en cas d'un eventuel PING. 

Zebot

Parfait, toutes les fonctions vitales d'un bot sont là. On peut 
les assembler pour faire un bot qui va se connecter et rester 
connecté indéfiniment : c'est Zebot, le bot zéro, et son homologue 
en Python Pybot (voir annexe).

On peut même faire un script Shell, qui effectue les opérations de 
notre "TP", puis rentre dans une boucle qui PONG; c'est le Sh-Bot.
Attention, c'est programmé au plus simple. On remarquera que le 
programme plante si on flood le bot par exemple. A perfectionner ! 

Sockets

Introduction

Zebot, tel qu'il a été construit, n'a aucun avenir. On verra le 
problème de structure tout à l'heure, mais avant cela il y a deux 

problemes de socket : 

Zebot a une socket bloquante : il ne peut absolument rien faire 
pendant qu'il fait son read(sock, buff, MAX_SIZE-1). 
Zebot n'écoute que sur une seule socket. 
Or un bot doit pouvoir faire plusieurs choses pendant qu'il 
écoute sur le réseau, et il doit aussi pouvoir écouter sur 
plusieurs sockets, s'il accepte les DCC CHAT par exemple. 

Select/fd_set

Ce paragraphe va etre très technique, mais apporte une solution 
propre à nos deux problèmes. 

fd_set 

On déclare une variable globale de type fd_set, nommée fdused. 

#include <string.h> /* FD_SET */ 
extern fd_set fdused; /* liste des sockets sur lesquelles on 
fait le select */ 

Puis on suit la procédure suivante : 

Initialisation 

Une petit fonction d'initialisation : 

void initsocket(void) 
{ 
sockmax=0; 
FD_ZERO(&fdused); /* initialisation de fdused */ 
} 

Ajout d'une socket 

A chaque fois que l'on va ouvrir une nouvelle socket (un nouveau 
DCC CHAT ou une nouvelle connexion à un serveur), on va appeler 
la fonction suivante : 

void addsocket(int sock) 
{ 

FD_SET(sock,&fdused); /* on note dans fdused que la socket 'sock' 
est utilisee */ 
if(sock>sockmax) /* on a besoin de connaitre le plus grand */ 
sockmax=sock; /* numero de socket pour le select */ 
printf("Added sock %d\n", sock); 
} 

Effacement d'une socket 

Inversement, si l'on doit fermer une socket, on appellera : 

void delsocket(int sock) 
{ 
FD_CLR(sock,&fdused); 
if(sock==sockmax) 
{ 
while(--sock>0) 
if(FD_ISSET(sock,&fdused)) 
break; 
sockmax=sock; 
} 
} 

puis on fermera la socket : 

close(sock);

Select 

Maintenant, voyons comment nous allons pouvoir écouter sur toutes 
les sockets positionnées dans fdused, tout en faisant autre chose. 
La fonction select prend 5 arguments. Le premier est le numéro de 
socket le plus grand plus un ! (sockmax +1). Le second est notre 
fdused. Les 3e et 4e sont NULL. Le dernier est le temps au bout 
duquel on sortira du select même si on a rien reçu. C'est grâce 
à ce dernier argument qu'on pourra reprendre regulièrement la main 
pour faire autre chose (toutes les 100ms par ex.). 

Note : si on reçoit quelquechose, on sort tout de suite du select. 

fd_set fdread; 
int status; 
char buff[512]; 
struct timeval timeout={0L, 100000L}; /* .1 second max. in select */ 
memcpy(&fdread, &fdused, sizeof(fdused)); /* on fait une copie de fdused */ 
while((status=select(sockmax+1, &fdread, NULL, NULL, &timeout))<0) 
warn_log("receive: Error receiving socket"); 
timeout.tv_sec=0; /* timeout a été effacé par select */ 
timeout.tv_usec=100000; /* donc il faut le remettre a 0.1 sec */ 

Si la variable status est à 0, c'est qu'on est sorti par timeout, 
donc il n'y a rien dans les sockets. Par contre, si status n'est 
pas nul, il faut aller voir ce qui a été reçu sur chacune des sockets. 

Supposons qu'on ait une structure socket, avec un numéro de socket, 
socket.number, et un pointeur sur la socket suivante, socket.next 
(le dernier pointant sur NULL). first_socket est notre première socket. 

for(reactor=first_socket; reactor!=NULL; reactor=reactor->next) 
if(FD_ISSET(reactor->number, &fdread)!=0) /* On regarde s'il y a 
quelquechose dans cette socket */ 
read_msg(reactor); /* Il y a quelquechose, on appelle une fonction 
qui fera un read(reactor,...) */ 

On remarquera que le select ne lit pas les données. Il permet juste 
de savoir s'il y en a en attente ou pas.

Conclusion

On a maintenant le nécessaire pour gérer un nombre illimité de 
sockets. Il reste bien sur à écrire les fonctions read_msg qui 
lisent les messages reçu, les traitent, et réagissent en fonction 
de leur contenu. 

Configuration

Dernière chose avant de passer à la structure du bot : le parsage 
de la configuration. En effet, il ne faut pas faire comme dans 
Zebot où l'on a codé en dur l'adresse du serveur par exemple.
Généralement, on fait un fichier contenant les informations sur 
les serveurs IRC, un autre sur les utilisateurs du robot, avec 
leurs droits. Le robot doit lire ces fichiers au lancement, et 
sauvegarder sa configuration dedans au cours de son fonctionnement. 
Le parsage des fichiers est quelquechose d'assez fastidieux à coder 
en C. On peut utiliser Lex et Yacc. Ce système de fichiers de 
configuration permet de ne pas avoir à recompiler le bot à chaque 
changement de configuration, ce qui est appréciable !

Structure

Voilà, on y est ! Voyons d'abord les quatres fonctions du bot :
Le parser s'occupe de traiter les messages reçu sur les sockets. 
Le if s'occupe d'appeler les fonctions concernées par le message reçu. 
Les fonctions réagissent en fonction du message reçu. C'est le coeur 
du robot. 

La queue s'occupe de traiter les information sorties des fonctions 
pour les envoyer au serveur. 
 
La Queue

Il faut absolument faire une fonction qui récupère les messages 
générés par les fonctions et les envoie vers le serveur IRC. En 
effet, si toutes les fonctions envoient des données directement 
dans les sockets, on a aucun contrôle sur le débit envoyé. Si 
toutes les fonctions parlent en même temps, le bot va flooder 
le serveur IRC. Il risque alors de se faire déconnecter. Toutes 
les fonctions doivent donc impérativement envoyer leur données 
vers une fonction qui les stocke, et les envoie progressivement. 
Malheureusement, il n'y a pas d'algorithme sûr pour calculer le 
débit que l'on peut envoyer sans flooder le serveur. Il vaut 
mieux le déterminer expérimentalement, selon le serveur. 
S'il y a beaucoup de messages en attente, la fonction de queue 
peut se charger aussi d'optimiser : passer les messages 
importants avant les autres, regrouper les modes, etc... 

Le Parser

Le parser obtient les données brutes venant du serveur. Par exemple : 

:toto!hero@glop.via.ecp.fr PRIVMSG #glop :Salut ! 

Il va se charger par exemple de séparer le nick, le login et le 
host, et mettre tout ça dans un belle structure. Un peut aussi 
en profiter pour rechercher les droits de la personne en question 
dans une userlist enregistrée quelquepart. Par exemple : 

struct message { 
struct user { 
char *nick; 
char *login; 
char *host; 
int user_level; 
} *from; 
char *commande; 
char *to; 
char *texte; 
}; 

Ensuite, le parser passe cette structure au "if"... 

Le "If"

Il s'agit en fait de la moulinette qui va aiguiller la structure 
envoyée par le parser vers les fonctions qui doivent être appelées. 
Cela peut être une opération très basique, comme une succession de 
"if(!strcmp(parsed_msg->commande, "PRIVMSG")) ..." ou autre chose 
de plus compliqué (voir Lignus II, quand le site sera fait...). 

Les fonctions

Ce sont les fonctions qui constituent l'âme du bot. Les autres 
modules ne sont que des interfaces. Un fonction peut être très 
simple : quand elle reçoit un PING :%s, elle renvoie un PONG :%s, 
ou très complexe (selon l'imagination du concepteur). 

Listes doublement chaînées

Un bot, c'est plein d'allocations dynamiques. Il est donc 
conseillé d'utiliser des listes doublement chaînees : c'est 
plus pratique et plus sûr.


Annexes (fichiers joints dans le package) :
La version en C :
socket.c

Le RFC 1459 sur l'IRC
-irc_rfc_fr1459.htm

Fonction qui effectue un login en Python :
-log_in.py

Le même en C :
-log_in.c

Fonction qui écoute sur le socket que l'on a ouvert et répond en cas 
d'un éventuel PING (en python) :
-pong.py

Fonction qui écoute sur le socket que l'on a ouvert et répond en cas 
d'un éventuel PING (en C) :
-pong.c

Script de ZeBot en Python :
-pybot.py

Script de Zebot en C :
-zebot.c

Zebot en script sh --> ShBot :
-bot.sh

Et petit cado :

Connection à un serveur irc en python :

#! /usr/bin/python 
# On importe toutes les fonctions de la librairie "socket" 
from socket import * 

host = 'blured.via.blurhost.fr' 

# On resoud le nom de machine 
hostaddr = gethostbyname(host) 
# On ouvre une socket 
# AF_INET - type Internet
# SOCK_STREAM - type TCP (par opposition avec UDP) 
sock = socket(AF_INET, SOCK_STREAM) 
# Et on se connecte ! s
ock.connect(host, 6667) 
# Et voila ! 


Blured