- La realisation
- Fonctionnement Global:
- Les Statistiques
- Les points Faibles :
- Les requetes de type WHO :
- Le "design" des pages, certaines doivent etres ameliorees.
- Les problemes de deconnexions des serveurs IRC, si on perd un serveur, on perd un reseau jusqu'a reconnexion et donc les requetes seront moins fiables (puisque la recherche ne sera pas faite sur tous les reseaux sauf pour les channels qui sont stockes en memoire).
- Le redemarrage de l'application implique la perte des statistiques qui pour le moment ne sont stockees qu'en memoire.
- Les points Forts :
- Le systeme multiThread, chaque serveur est gere independemment, idem pour les clients HTTP. Il n'y a aucun interblocage, sauf si le Thread Parent principal se bloque mais il ne fait des operations qu'au demarrage. L'application est a ce stade non blocable, nous avons essaye d'eliminer pratiquement tout risque de blocage.
- Le systeme de requetes asynchrone, qui evite la file d'attente classique, une requete peut avoir lieu meme si une autre n'est pas terminee.
- La centralisation des donnees mondiales. C'est point le plus important et un des plus difficiles a realiser avec l'impossibilite d'interblocage.
- Le systeme de statistiques qui permet une visualisation Mondiale ou reseau par reseau plus visuelle et qui permet de faire des moyennes.
- La rapidite des requetes. Meme si elles dependent du temps que les serveurs IRC mettent a repondre pour les recherches d'utilisateurs, la plupart des requetes sont tres rapides, les plus rapides sont celles sur la recherche de canal grace a un systeme de Hashtable tres bien implementee par Java
- Code 100% Java qui permet d'utiliser cette application sur n'importe quelle plateforme. L'utilisation de cpu etant tres faible, l'application peut se lancer comme "daemon".
- Les futures Versions (2.0 etc ...)
- Amelioration de la requete WHO.
- Amelioration du Design des pages et des stats.
- Systeme de Logs pour les connexions et les erreurs.
- Systeme de stats stocke sur fichiers.
- Nouvelles stats (moyennes de channel, Graph d'influence des reseaux par rapport aux donnees mondiales).
- Possibilite de faire les stats sur 1 semaine, 1 mois, 1 annee (difficile a tester).
- Possibilite de notifier (NOTICE) un utilisateur sur IRC par l'envoi d'un message ecrit par le client HTTP.
- Lors de la recherche d'un channel, possibilite de connaitre les modes et utilisateurs (sans mode +i) de ce canal de discussion.
- ... (et encore plein d'autres idees !!).
La partie de l'application moteur de recherche va se connecter a un seul serveur de chaque reseau IRC (tous les serveurs d'un seul reseau etant connectes entre eux, mais les reseaux ne le sont pas entre eux). Comme un serveur IRC possede une copie en memoire du reseau ou il est connecte (utilisateurs, channels, links ...), il n'est pas utile d'etre connecte a plusieurs serveurs d'un meme reseau.
Le moteur collecte par le protocole IRC les informations sur les stats
(LUSERS), les links (LINKS) toutes les 6 minutes grace a un timer. Les
informations sur les channels (LIST) sont collectees toutes les 24 mn (4x6mn).
Les informations sur les utilisateurs sont faites en temps reel et
ne sont pas stockees, car elles sont trop volatiles (IRC est un protocole
temps reel), les utilisateurs se connectent et deconnectent rapidement,
ils peuvent changer de canal de discussion facilement.
Lorsqu'un client netscape par exemple fait une requete HTTP pour chercher un utilisateur, la partie HTTP analyse la requete et cree un Thread, qui se charge de stocker la requete dans une liste du moteur et de lui demander de lancer la requete. Lorsque le moteur a recu la reponse de tous les reseaux, il redirige les resultats sur le bon Thread (il peut y avoir plusieurs requetes a la fois) et met a jour sa liste de requetes. Le Thread qui avait lance la requete genere la page et la renvoie sur le client netscape en format HTML.
De cette facon, une requete lance apres une autre peut arriver avant
la 1ere. il est impossible de bloquer les requetes, si une reponse n'arrive
pas, les autres requetes peuvent toujours continuer. Le TimeOut se chargera
de stopper le Thread qui attend la requete et signifier au client un TimeOut.
Les statistiques sont realisees grace a un timer (Un Thread qui tourne
en permanence et qui lance une methode update() selon un cycle).
A chaque cycle, des commandes differentes sont envoyees (LINKS,LUSERS)
aux serveurs IRC connectes, les moyennes sont effectuees uniquement lorque
tous les reseaux ont repondus (a condition d'etre connectes). Cet aspect
est en cours d'amelioration, qui permettra de donner les stats meme si
tous les reseaux n'ont pas repondus avec un pourcentage de fiabilite (Cf
: futures versions).
Elles ne sont pas correctement redistribuees, du fait que le serveur
IRC n'indique pas pour quelle requete est la reponse. La reponse va au
premier WHO dans la liste des requetes. Le second aura la suite des reponses
quand le premier aura recu un message fin WHO, le troisieme aura la suite
quand le second aura recu un fin WHO etc ...
Ce point va etre ameliore dans les versions suivantes.
En effet, si le protocole IRC est un standard, chaque reseau possede ses petites specificites (pour la commande LUSERS, IRCNET ne renvoie pas exactement les memes infos que sur EFNET ou UNDERNET), et ses interdictions ou restrictions.
Ainsi, il n'est pas possible pour le moment d'obtenir la liste des channels sur IRCNET car les serveurs disposent une variable "SENDQ limit" qui empeche le serveur d'envoyer un trop gros flux de donnees a un utilisateur. Or la commande LIST occasionne un trop gros flux. La solution est de demander a un administrateur d'un serveur sur IRCNET de faire une classe speciale pour l'IrcSearch permettant un SENDQ plus important (en cours de negociation).