Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut 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é.

  2. #2
    Membre émérite
    Avatar de mavina
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 479
    Points
    2 479

    Par défaut

    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.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  3. #3
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    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.

  4. #4
    Membre émérite
    Avatar de mavina
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 479
    Points
    2 479

    Par défaut

    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.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  5. #5
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    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.

  6. #6
    Membre émérite
    Avatar de mavina
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 479
    Points
    2 479

    Par défaut

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

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  7. #7
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    Citation Envoyé par mavina Voir le message
    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.

  8. #8
    Membre expérimenté
    Avatar de granquet
    Profil pro
    Étudiant
    Inscrit en
    octobre 2005
    Messages
    1 201
    Détails du profil
    Informations personnelles :
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 201
    Points : 1 398
    Points
    1 398

    Par défaut

    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
    click my www
    ............|___
    ...................\
    .................._|_
    ..................\ /
    ..................."

  9. #9
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    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.

  10. #10
    Membre émérite
    Avatar de mavina
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 479
    Points
    2 479

    Par défaut

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

    Si oui, contactes moi

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  11. #11
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    Citation Envoyé par mavina Voir le message
    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.

  12. #12
    Membre émérite
    Avatar de mavina
    Homme Profil pro
    Développeur Java
    Inscrit en
    octobre 2004
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Chine

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2004
    Messages : 1 812
    Points : 2 479
    Points
    2 479

    Par défaut

    Regarde mes articles ^

    F.
    Développeur Java / Flex à Shanghai, Chine
    mes publications
    Mon dernier tutoriel : Messages Quit IRC : explications

    La rubrique IRC recrute des redacteurs : contactez moi

    Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.[/SIZE]

  13. #13
    Membre averti
    Avatar de CORBASE
    Profil pro
    Étudiant
    Inscrit en
    avril 2006
    Messages
    246
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : avril 2006
    Messages : 246
    Points : 428
    Points
    428

    Par défaut

    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
    Rien n'est impossible, c'est juste une question de temps
    C'est quoi le PureBasic ?

  14. #14
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    Citation Envoyé par CORBASE Voir le message
    [...]

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

  15. #15
    Membre expérimenté
    Avatar de granquet
    Profil pro
    Étudiant
    Inscrit en
    octobre 2005
    Messages
    1 201
    Détails du profil
    Informations personnelles :
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 201
    Points : 1 398
    Points
    1 398

    Par défaut

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

    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
    click my www
    ............|___
    ...................\
    .................._|_
    ..................\ /
    ..................."

  16. #16
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    Citation Envoyé par Dark_Ebola Voir le message
    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.

  17. #17
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    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.

  18. #18
    Membre confirmé Avatar de T`lash
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Saint-Pierre-Et-Miq.

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Biens de consommation

    Informations forums :
    Inscription : septembre 2007
    Messages : 374
    Points : 518
    Points
    518

    Par défaut

    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.

Discussions similaires

  1. Avantages et inconvénients par rapport au C++ ?
    Par clovis dans le forum Smalltalk
    Réponses: 3
    Dernier message: 11/07/2009, 17h58
  2. Réponses: 3
    Dernier message: 16/06/2006, 16h36
  3. [Conseils] Programmation d'un protocole IRC
    Par Malko06 dans le forum IRC / mIRC
    Réponses: 2
    Dernier message: 25/03/2006, 01h50
  4. Socket et protocole IRC
    Par EpOnYmE187 dans le forum WinDev
    Réponses: 8
    Dernier message: 10/02/2006, 14h54
  5. Docteur ès Sciences : avantage ou inconvénient ?
    Par overmac dans le forum Etudes
    Réponses: 72
    Dernier message: 15/11/2005, 12h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo