Avantages & Inconvénients du protocole IRC

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é.

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.

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.

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 :aie:

Je sais pas comment tu penses ton protocole ...

F.

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.

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

F.

Citation:

---

Envoyé par mavina

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

F.

---

Non, mais j'ai bien avancé dans les concepts de base.

Cela ne fait que depuis quelques jours que je me suis penché dessus, et c'est pour ça que j'ai créé ce topic, pour ne pas m'orienter dans de mauvaises directions.

salutations :)

ton idée de protocole est interressante, juste un petit point qui me fait réagir:
tu parle d'une toile (et pas une étoile comme cité précedemment) permettant d'assurer la continuité du service, mais tu veux utiliser un serveur maitre.
hors il me semble que la fonctions du serveur maitre (calcul de route dynamique) pourrait être délocalisée sur les noeuds de ton réseau

je prend comme exemple le protocole RIP qui transmet seulement la liste des coûts pour atteindre une destination en passant par un noeud voisin.
ainsi, chaque noeud connais (très rapidement) le plus court chemin et chaque routeur est indépendant.

si tu peux te permettre de faire du multicast, tu peux t'inspirer d'OSPF (sans BDR) qui lui transmet la topologie complête du réseau à tous les noeuds
ainsi chaque noeud se represente le réseau comme un arbre et peux faire du load balancing

Si je me base sur un serveur maître c'est simplement afin que la topologie soit gérée par celui-ci.
Cela afin d'optimiser les connexions.
Les interconnexions ne sont pas standardisées, mais c'est l'implémentation du serveur maître qui en décide.

Je ne sais pas si je me suis bien exprimé, mais si ce n'est pas encore clair je vais essayer de reformuler.

Simple question T`lash ça t'interesserai de faire un article sur les forces et faiblesses de l'IRC ?

Si oui, contactes moi

F.

Citation:

---

Envoyé par mavina

Simple question T`lash ça t'interesserai de faire un article sur les forces et faiblesses de l'IRC ?

Si oui, contactes moi

F.

---

Je vais voir ce que je peux en faire, mais c'est le genre d'articles à polémique car les faiblesses pour les uns sont des avantages pour d'autres.
Selon l'utilisation qui en est faite.
Je vais essayer en tout cas et si j'en tire quelque chose de bien je t'envoie le tout.

Par contre, il s'agirait d'un article sous quelle forme ?
Donne moi un exemple sur le site (peu importe le sujet) pour que je sache de quelle manière orienter la prose.

Regarde mes articles ;)^

F.

Salut :)

Bon moi je voulais revenir sur un peu toute la discussion (désolé je suis pas très présent ces temps-ci sur le forum, trop de boulot).

Sinon, le protocole IRC est quand même robuste, on parle de netsplit, etc .. alors que bon ce n'est pas non plus un problème très très fréquent. Mais je conçois tout à fait que cela est un problème.

Ensuite, le CTCP doit aussi rester du CTCP, les clients doivent pouvoir communiquer entre eux, cela à permis de faire du p2p, et d'ouvrir la porte aux DCCs. De plus, cela reste une solution de "secours", en effet, même si tu perds la connexion avec ton serveur IRC, le DCC lui étant de type TELNET, client/serveur p2p, tu garde la main. Enfin, voilà :)

Ensuite, ton idée de créer un nouveau protocole de discussion TR est une bonne idée, cependant ne pas faire l'analogie avec IRC. A créer un nouveau mode de communication je pense qu'il vaut mieux que tu te démarque de l'IRC, et de ne pas essayer de faire un "surcouche".
Essaye plutot de créer autre chose, plus personnel, avec d'une part les fonctionnalité que tu veux qu'il gère puis apèrs tu parlera d'architecture.

On part du besoin bussiness, donc ici les fonctionalités sont ces fameux besoins. Ensuite, il suffit de passer en architecture logicielle et voire même matérielle. Je te dis ça car je vois que tu parle de A* ou Dijkstra avant même d'avoir la totalité des fonctionnalités que tu veux apporter.

Bref, moi ce projet m'interesse, donc si tu veux quelqu'un pour t'aider, je serais partant (enfin si j'adhère au projet dans sa globalité).

Personnellement j'ai une approche un peu différente, je verrais bien une approche plus SOA, avec un frontal (doublé pour la redondance) qui dispatche sur X entrées serveurs ou services. Mais bon ça reste encore une théorie.

Voilà, à la prochaine

Citation:

---

Envoyé par CORBASE

[...]

On part du besoin bussiness, donc ici les fonctionalités sont ces fameux besoins. Ensuite, il suffit de passer en architecture logicielle et voire même matérielle. Je te dis ça car je vois que tu parle de A* ou Dijkstra avant même d'avoir la totalité des fonctionnalités que tu veux apporter.

[...]

---

En fait, si tu as l'impression que je mets la charrue avant les bœufs, c'est simplement qu'à chaque fois que je pense à une fonctionnalité, j'en teste la faisabilité en réfléchissant au code qu'il me faudrait mettre en place.

Ainsi, je peux voir que certaines pistes sont à suivre ou à abandonner.

Cela fait en quelque sorte partie du travail préalable au vrai travail de fond ; étude de ce qui se fait, de ce qui serait à garder, à améliorer, à totalement repenser, à ajouter.
Ensuite, est-ce que cela est faisable. Pour cela, il suffit de faire un test et ainsi on voit ce qui pourrait clocher dans l'approche théorique.

Je prends pour base IRC car c'est le protocole le plus utilisé et qui a le plus plu.
Je passe une bonne partie de mon temps dans sa RFC pour en assimiler au mieux le fonctionnement. Mais ce n'est encore là qu'une piste de réflexion.
Si ces recherches montre qu'une évolution d'IRC est la meilleure solution ce sera ce vers quoi je vais pencher, mais c'est loin d'être sûr.

Quand le contrat à remplir sera bien dégrossi, il sera alors temps de former un véritable groupe de réflexion pour confirmer cela et par la suite établir une spécification.


Si alors cela t'intéresse, je me souviendrais de toi ^^



PS: C'est juste dommage que cette section du forum ne soit pas plus visitée car il aurait été intéressant d'avoir plus d'avis sur le protocole de chat orienté salon le plus utilisé.

question à 20 cents: pourquoi partir sur une base IRC et pas XMPP ?

parce que j'ai l'impression que tu vas finir par ré-inventer XMPP ;)

je reviens sur cette notion de serveur maître que je trouve toujours inutile (si tu souhaite toujours en parler et m'exposer ton point de vue):

sans serveur maître:
-aucun noeud 'vital' à ton réseau, aucun serveur n'est plus important qu'un autre => grande robustesse aux pannes
-propagation de la topologie du réseau via multicast => chaque serveur vois la toile dans son ensemble et peux ainsi faire du load balancing en temps réel beaucoup plus finement que si c'était géré par un serveur central
-un noeud perdant toutes ses connexions 'statique' peux toujours se raccrocher à un autre noeud => pratiquement impossible d'isoler un noeud du réseau (à moins de couper le backbone ... jvois pas :D).

le seul avantage que je vois à un serveur maître, c'est que cela parait plus facile à implémenter (plus statique, plus facile à se représenter).
mais je suis persuadé que c'est une illusion et que tu ne peux tirer que des avantages d'une gestion décentralisée

Citation:

---

Envoyé par Dark_Ebola

question à 20 cents: pourquoi partir sur une base IRC et pas XMPP ?

---

XMPP est orienté liste de contacts mais peut faire dans le chat de salon.
IRC est orienté salon mais peut faire dans la messagerie instantanée avec liste de contacts.

Le but premier de mon projet est de mettre en place un protocole complet qui ne soit pas plus orienté dans une direction que dans une autre, mais ne perde pas pour autant dans les deux domaines à force de compromis.

Il y a en effet plusieurs similitudes avec le protocole de Jabber au niveau des fonctionnalités même si cela reste fondamentalement différent.

Je cherche à allier les avantages des deux protocoles.

---------------------------

Un serveur maître ne pose pas forcément de problème face aux pannes si un autre serveur du réseau prend automatiquement la relève en cas de coupure.
Puisque la configuration du réseau est transmise à tout nouveau serveur qui se connecte, ce dernier est tout à fait apte à devenir serveur maître en cas de coupure du noyau.
Il suffit simplement de créer une hiérarchie : à la connection un serveur indique si peut techniquement devenir calife à la place du calife, et si c'est le cas sa position dans la liste des potentiels successeurs est envoyé à tout le réseau en même temps que le message de connexion effective.

Pour ce qui est du routage je ne suis pas encore fixé car tout faire calculer par un serveur central a en effet l'air de poser plus de problèmes qu'il n'en résout.

Par contre, cette approche à pour but de gérer les connexions des nouveaux serveurs afin de laisser le choix de la topologie réseau à un centre décisionnel afin d'optimiser les échanges et la charge de l'ensemble des serveurs.
En cas de disparition massive de serveurs sur le réseau, le serveur maître peut ordonner la suppression ou l'établissement de connexion inter-serveurs.
Si on laisse à chaque serveur le loisir de décider cela par lui-même, selon l'implémentation on va se retrouver avec un réseau en morphose perpétuelle nécessitant une mise à jour continuelle des tables de routage.

Je continue de dresser la liste des avantages et inconvénients d'IRC et je lui trouve un avantage certain qui lui vient directement de son grand âge : la longueur de ses messages.

Même si à cause de ses spécificités structurelles au niveau de l'architecture il est nécessaire d'envoyer de très nombreux messages qui pourraient être évités avec une autre structure chacun de ses messages est très succinct.
Ce qui économise les ressources réseaux. Peut-être que cela peut paraitre minime, mais fait tout de même une sacré différence par rapport à XMPP par exemple dont beaucoup trouve le XML utilisé bien trop verbeux.


Au niveau des très gros inconvénients il y a qu'un réseau IRC ne peut être composé d'un trop grand nombre de serveurs car les informations des utilisateurs et des canaux doivent être répercutées sur l'ensemble du réseau.
Comme en plus la topologie est en arbre le chemin ne doit pas être trop long entre deux serveurs (dès le début du protocole il était évoqué le fait de pouvoir boucler l'arbre).



~¤~¤~¤~¤~¤~¤~¤~¤~¤~

Pour Dark_Ebola :

J'ai abandonné l'idée d'un serveur maitre, mais ai opté pour une notion de divers services noyau reconnu par le protocole dont l'absence sur le réseau provoque une modification du comportement de tous les serveurs.

Après de plus ample recherche, XMPP pourrait très bien remplacer IRC par ses capacités de modularité, le problème est que les extensions existantes fournissant les services homologues à ceux d'IRC (MUC en particulier) ne sont pas particulièrement bien conçues.

Il faudrait donc mieux améliorer ces extensions plutôt que de créer un protocole de plus dans la jungle des RFCs.


Pour en revenir aux choses qui auraient pu être mises en place pour améliorer IRC, une hiérarchisation des channels en catégories aurait pu faciliter la recherche d'un salon à rejoindre.
Ou plutôt la possibilité de leur attribuer des propriétés telle que la langue afin de classer la liste qui peut prendre des dimensions astronomiques sur les principaux réseaux.