ANTIFLOOD SIMPLE ... MAIS PUISSANT

Il s'agit ici d'une base d'antiflood (le noyau quoi) permettant d'être utilisée très facilement n'importe où. C'est à dire que vous pouvez à la fois vous en servir pour vous et pour votre bot fait en socket.

>> Ce script est fait uniquement en hash tables et surtout sans aucuns timers !

Sommaire :
En haut : Des explications théoriques bien rébarbatives.
Au milieu : Le code source (2 aliases de 12 lignes en tout) suivit d'un exemple d'utilisation.
En bas : Aide sur les deux fonctions.

Prenons un anti-flood au hazard et reglons le sur 5 messages toutes les 10 secondes maximum, maintenant à l'aide d'un script effectuons la manipulation suivante :

A t=0 : on envois 1 message => l'anti-flood demarre un timer, il me reste 9 message max.
A t=4,5~4,9 : on envois 9 messages => plus que 0 message ! Je passe tout juste.
A t=5 : le timer s'arrête, j'ai envoyé 10 messages ; je suis sous la barre donc l'anti-flood me supprime de sa base de données.
A t=5,1~5,5 : on envois 10 messages (l'anti-flood démarre un nouveau timer : il me reste 0 message, c'est juste mais ca passe)

Vous constaterez que bien qu'ayant envoyé pas moins de 19 messages en 1 seule seconde la majorité des anti-flood vous laissent passer. D'où tout l'interêt de mémoriser la date d'apparition de chaque message de chaque utilisateur (dans la limite du temps imparti : 10 secondes).

Recommandations d'usages :

Ne faites pas plusieurs tables de hachages si vous utilisez ce script de plusieurs façons à la fois ! En effet vu la facon dont celles-ci fonctionnent, ce genre d'utilisation est leur spécialité, vous pouvez la grossir autant que vous voulez sans ralentir le script. Augmentez juste en conséquance l'intervalle possible de clé (Que j'ai appelé <taille htable> et qui est utilisé dans hmake) et pensez aussi a maintenir des identifiant <ident> différent d'une version à l'autre pour éviter les collisions. Pour obtenir des identifiants différents à coup sûr, vous pouvez précéder chaque occurance d'une lettre unique "p" pour votre antiflood perso, "b" pour celui du bot, etc.

Je n'ai pas vérifié mais il me semble que vous pouvez modifier les paramêtres <nbr msg> et <secs> en cours de route sans (trop de :p) dégâts (vérifiez par vous-même avant si vous comptez modifier fréquement ces paramêtres).

Remarque - Vous pouvez obtenir de l'aide sur les deux fonctions utilisées en les tapant sans paramêtre :
/antiflood.ontext
/antiflood.onnick

Explications concernant l'exemple :
Etant donné que notre exemple traite chaque canal à part, il est nécessaire que le "onnick" s'applique à chaque canal que vous avez en commun avec la personne. Notez que l'on utilise $cid pour éviter le cas où vous auriez le même server/canal ouvert par deux connections (ou plus).

Décomposition des paramêtres dans la fonction /antiflood.ontext :
<ident> = $nick $+ @ $+ $cid $+ # ; Ceci permet que le script traite chaque canal et chaque network différament (cf. explications)
<nbr msg> = 5 ; Nombre de message que l'on peut dire ....
<secs> = 3 ; .... sur le nombre de secondes.
<nom htable> = antiflood
<taille htable> = 10 ; cf. Dans l'aide à "hash table", c'est le N de hmake
<fct onflood> = kick # $nick Pas de flood ! ; commande à executer en cas de flood, pensez à mettre un alias perso pour faire plusieurs commandes.

Décomposition des paramêtres dans la fonction /antiflood.onnick :
<ident> = $nick $+ @ $+ $cid $+ $comchan($nick, $+ %i) ; ancien identifiant de la personne pour chaque canal
<newident> = $newnick $+ @ $+ $cid $+ $comchan($nick, $+ %i) ; nouvel identifiant de la personne la aussi pour chaque canal
<secs> = 3 ; idem que tout a l'heure
<nom htable> = antiflood ; idem que tout a l'heure

Note de fin : Notez que ce script peut s'utiliser pour contrôler la fréquence de n'importe quel système de flux de donnée si l'intégrité ou/et l'ordre ne sont pas importants (on peut en effet à la place du kick mettre un système de timer qui relance la commande un peu plus tard).