Discussion :

[T`lash]

Comme je l'ai déjà énoncé >> ici <<, j'ai dans l'idée de développer une alternative au protocole IRC et, afin de ne pas laisser derrière de points importants, j'aimerais connaître votre avis surce qui fait la force d'IRC et quelles en sont les faiblesses.

Si vous avez déjà des problèmes que vous n'avez pu résoudre lors du développement d'un client (ou serveur) IRC, ou même dans son utilisation, faites m'en part afin de diriger mon approche.

De même, si vous avez eu à utiliser des fonctionnalités non classiques du protocole que vous avez particulièrement appréciées, il serait bête de passer à côté.

[mavina]

Pour moi, contrairement à ce que tu penses, le fait que le réseau ne soit pas redondant, et donc le fait qu'un serveur qui se déconecte avec un autre serveur ne crée pas de déconexion du client est un gros gros plus. Deux réseaux distincts sont créés et ils sont réunis une fois les deux serveurs reconnectés entre eux.

Tu pourrais entammer le débat en disant ce qui sont pour toi les forces et les faiblesses de l'IRC ?

F.

[T`lash]

Pour moi, déjà, ce serait surtout des fonctionnalités qu'il serait intéressant d'ajouter ; tel un type de message "User Command" qui ne serait pas vérifié par les serveurs et s'adressant directement au client avec une option "message d'erreur si le client cible ne reconnait pas cette commande".

Cela permettrait certaines choses qui n'était jusque là permises quand CTCP.

En fait, plusieurs clients IRC (ou script mIRC) ont ajouter des fonctionnalités en trouvant des astuces de détournement de l'utilisation standard du protocole IRC.
Mon but serait de normaliser ces échanges.


Pour ce qui est du netsplit, je ne vois pas en quoi tu peux trouver ça une bonne chose....

Mon approche est semblable à celle du réseau Internet : les connexions entre les routeurs forment une toile qui permet d'assurer une continuité de service lorsque l'une des connexions est coupée.

Cela permettrait d'assurer l'intégrité du réseau de chat en tout temps et empêcherait les collisions qui apparaissent lors de la resynchronisation des serveurs IRC.

En mettant en place un réseau qui s'autogère et calcul lui-même les connexions nécessaires ainsi que le routage des messages on modernise un système de chat qui prend de l'âge.

Lorsqu'IRC a été conçu cela ne paraissait pas gênant, mais j'ai vu plusieurs personnes quitter des réseaux IRC à cause de netsplits trop fréquents qui peuvent être totalement évités si le protocole gère cette état de fait à la base.

[mavina]

Bah ce que tu décris est le CTCP (Client To Client Protocol). Il ne passe pas par le serveur, c'est un protocole indépendant du protocole IRC.

Pour le net-split, je suis d'accord pour dire que c'est génant, mais certes le réseau en étoiles d'internet permet de pailler une quelconque faille. Il ne serait pas raisonnable de penser un protocole de chat sur un systeme de milliers de serveurs inter-connectés entre eux. Ce serait une demande de moyens énormes. même une dizaine, ca fait 9 connexions pour chaque serveur, 9 synchronisations à faire, etc etc...

imagine dans un réseau en étoile

Je sais pas comment tu penses ton protocole ...

F.

[T`lash]

Justement, certaines choses devront toujours passer par le CTCP tel l'échange de fichiers, mais d'autres échanges devraient pouvoir passer par le serveur afin qu'un client reste un client (avec les CTCP, l'un des deux doit forcément jouer le rôle de serveur).

Pour ce qui est des connexions inter-serveurs, bien sûr qu'il serait totalement idiot (et inutile) de connecter tous les serveurs entre eux.
Pour mon implémentation de référence, je table plutôt pour un maximum de 3 connexions entrantes et 3 connexions sortantes.

Les raccords étant gérés par le serveur maître, ce dernier pouvant ordonner au autres d'initier une connexion ou d'en clore une.
Si une connexion est coupée, il va demander son rétablissement.
C'est également son rôle de calculer les tables de routage car c'est le seul à connaître le tramage du réseau.
De même, si un serveur dans le centre de la toile vient à totalement disparaître, il devra :
1 - ordonner aux serveurs hôtes de celui qui vient de s'éteindre d'autoriser les connexions venant du dernier serveur de la toile.
2 - demander à ce dernier serveur d'initier les connexions (donc 3 au maximum) et d'en accepter 3 autres particulières.
3 - demander aux serveurs qui étaient clients du serveur déconnecté de se connecter au serveur de remplacement.
4 - Mettre à jour la table de routage du serveur "rustine".
5 - S'assurer que l'étape 4 à bien été aboutie puis mettre à jour toutes les autres tables de routage.
6 - Enfin ordonner au serveur "rustine" de clore ses anciennes connexions.


Cela paraît beaucoup de choses mais ce ne sont que des opérations standards. La charge de travail est conséquente pour le serveur principal si le nombre de serveurs est important, mais plusieurs lignes dans les tables de routage sont des sous éléments d'autres routes alors il suffit de réellement optimiser l'algorithme de calcul.
C'est également pour cela que je veux utiliser un algorithme A* plutôt qu'un Dijkstra comme c'est le cas des routeurs Internet car le passage par un serveur a un coût selon les services qu'il héberge : le serveur principal à un surcoût comme tous les serveurs hébergeant un service tel que ceux équivalent aux traditionnels NickServ, ChanServ et autres qui sont directement reconnus par le protocole (le fichier de configuration du serveur principal définit quels sont les services disponibles et qui héberge chacun d'eux ainsi que le surcoût éventuel à inclure dans l'algorithme de routage).

C'est finalement plus optimisé qu'il n'y parait car un message ne traverse pas plus de serveurs qu'il n'a besoin. Sur un petit réseau la charge supplémentaire du serveur principal sera quasi-inexistante et le réseau sera analogue à un réseau IRC, mais sur un plus gros réseau, le serveur principal gèrera le traffic de sorte que même si lui a plus à faire lors d'un changement de configuration des connexions, l'ensemble des autres auront moins de travail inutile.

[mavina]

Tu as déjà défini le protocole dont tu parles ?

F.