Avancées importantes dans le support de la voix sous Jabber/XMPP

Posté par . Modéré par Mouns.
0
17
déc.
2005
Technologie
Ces derniers jours ont été riches en événements autour du support de la voix sous Jabber/XMPP.

En effet, la Jabber Software Foundation (JSF) a publié un ensemble de protocoles appelé "Jingle" permettant de gérer les connexions multimédia de pair à pair. Actuellement deux protocoles sont disponibles :
  • "Jingle Signalling" : protocole de base pour toute connexion multimédia

  • > "Jingle Audio" : protocole spécifique aux communications de type voix sur IP

Ces deux protocoles ont été rédigés en collaboration avec Google et sont très proches du protocole utilisé dans le logiciel Google Talk. Pour faciliter l'implantation de ces protocoles, Google a publié sous licence BSD une bibliothèque en C++ directement extraite du code de Google Talk. Cette bibliothèque est actuellement en train d'être intégrée au client Jabber Psi.

Jingle semble déjà séduire de nombreux acteurs du monde Jabber et devrait être prochainement intégré aux produits d'Antepo, Cerulean Studios (Trillian), Coversant, Digium (Asterisk), Gaim, Jive Software, Novamens, Psi, SAPO, et Tipic. Comme l'explique Peter Saint Andre (le président de la JSF) sur son blog, les précédentes tentatives de la JSF pour définir un protocole de transport de la voix ont reçu jusqu'à présent des retours peu favorables. Notamment le protocole TINS qui définit comment négocier une session SDP par XMPP est souvent jugé trop compliqué. Les protocoles Jingle sont donc censés résoudre ce problème en proposant une solution plus intégrée à XMPP là où TINS était focalisé sur la facilité de compatibilité avec SIP. Néanmoins, la Jabber Software Foundation travaille actuellement à normaliser la façon dont Jingle devrait s'interfacer avec SIP, H323 et IAX. La complexité d'interface XMPP/protocole externe devrait donc être ramenée au niveau des passerelles (côté serveur), ce qui a toujours été la philosophie de Jabber.

Jingle est actuellement au tout début de sa phase de normalisation (les protocoles ont pour l'instant le statut « expérimental ») et évoluera par le processus de normalisation standard de la JSF auquel n'importe qui peut prendre part à travers la liste de diffusion Standards-JIG.

Aller plus loin

  • # routeur NAT

    Posté par . Évalué à 9.

    une question serait de savoir si ils on prévu un systeme pour communiquer avec des gens qui utilisent un routeur NAT, ce qui est très courrant.

    Par exemple Skype (qui n'est pas une référence du libre) utilise un systeme de peer-to-peer qui permet d'etablire un connexion entre nimporte qui même deux personnes derière un routeur NAT.
    • [^] # Re: routeur NAT

      Posté par (page perso) . Évalué à 9.

      A ce propos, je signale que la voIP de GoogleTalk fonctionne parfaitement sur un NAT et derrière un Proxy.
      Je ne sais pas trop par quel port passe tout ce bazar mais ça passe très bien...

      Alors étant donné que les protocoles sont à priori très proches, gageons qu'il en soit de même pour Jingle !

      Mais j'ai eu des échos comme quoi ça ne se passait pas spécialement bien avec SIP.

      En tout cas, ça ressemble à un grand pas pour la IM/voIP libre.
      • [^] # Re: routeur NAT

        Posté par . Évalué à 6.

        Le NAT se passe très bien avec SIP. En tout cas avec le futur gnomemeeting 2.0, on n'a plus besoin d'ouvrir quoi que ce soit pour que les choses se passent impeccablement.

        Snark sur #gnomemeeting
      • [^] # Re: routeur NAT

        Posté par . Évalué à 5.

        Et juste par curiositée, vous savez comment ça marche quand on est derière un routeur NAT, firewall ou passerelle ?

        j'ai plusieures supositions, mais ça n'est que des élucubrations.

        I - Si il n'y en a qu'un des deux qui est derière un routeur NAT :
        c'est le client deriere le routeur NAT qui contacte l'autre qui est joignable dirrectement

        II - si les deux sont deriere un NAT :

        - Magie noire
        - passerelle sur un server
        - passerelle sur d'autres clients qui sont accessible en entrée

        je m'intéroge là dessu depuis que j'ai vu skype fonctionner avec deux ordi deriere un fire-wall.
        • [^] # Re: routeur NAT

          Posté par . Évalué à 8.

          Pour sip tu peux passer par des proxy.

          Pour skype c'est tu p2p, donc tu passe par d'autres clients (d'ou les pb de secu car tu sais pas trop ce qui passe par ton reseau...)
        • [^] # Re: routeur NAT

          Posté par . Évalué à 4.

          Quand on est derrière du NAT, il y a plein de cas possibles.
          Si ce n'est pas ce qu'on appelle du NAT symmétrique, alors on peut toujours réussir à passer Directement en NAT to NAT sans utiliser de passerelle. A première vu on se dit que c'est pas possible, mais si! suffit de faire transiter les flux en udp, et de savoir ou envoyer (qu'elle ip et quel port).

          Pour le cas ou l'un des deux est dans un NAT symmetrique, alors on a le choix, passer par une passerelle spécifique au protocole ou passer par une passerelle générique (appelée TURN, cf draft en cours à l'ietf). La passerelle, après elle peut être soit dédiée sur un serveur central, soit sur un client dont le réseaux n'est pas du NAT symmetrique.

          ça c'était pour les flux audios eux mêmes... pour permettre à SIP/SDP de passer lui aussi le NAT, on doit utiliser des serveurs STUNs (standard de l'ietf) pour résoudre les problèmes d'adressage du protocole.
  • # Génial!

    Posté par (page perso) . Évalué à -10.

    Plus qu'a configurer ma caméra comme webcam.
    Enfin si ma caméra est reconnue... humm, une bonne séance bidouillage en perspective.


    /me RFTM.
    • [^] # Re: Génial!

      Posté par (page perso) . Évalué à 4.

      Dans le titre de la depeche, c'est marqué "support de la voix" et la lib s'appelle jingle-audio. Donc AMA une carte son suffit pour l'instant. Par contre, OpenWengo en plugin pour FF à l'air en cours d'achevement d'apres le glazblog. Par contre je sais pas si ca marchera sous linux.
      • [^] # Re: Génial!

        Posté par (page perso) . Évalué à 10.

        > OpenWengo en plugin pour FF à l'air en cours d'achevement d'apres le glazblog

        s/à l'air en cours d'achevement/est achevé ;-)

        > Par contre je sais pas si ca marchera sous linux.

        oui, ça fonctionnera sous linux, toutefois, la version windows sortira avant...
  • # Il manque Kopete dans la liste

    Posté par (page perso) . Évalué à 6.

    Vu ce qui est dis dans la mailing list et sur #kopete, Kopete pourrait etre rajouté dans la liste des logiciels qui vont implémenter Jingle. Sinon, il est vrai que Jingle-video n'existe pas encore, mais ça va suivre apres.

    En fait, on peut tout à fait penser que d'ici 1 an, on aura plein de clients win/linux/osx qui supporteront un Jabber audio/video, des serveurs Jabber capable d'absorber de gros traffics (via google), et donc il sera enfin temps de faire migrer ses contacts.
    • [^] # Re: Il manque Kopete dans la liste

      Posté par . Évalué à 6.

      J'ai cru comprendre que Kopete utilisait libiris, développée par le projet Psi, pour le support Jabber.
      Dans ce cas, on effectivement de bonnes raisons de penser que Kopete supportera Jingle peu de temps après Psi.
    • [^] # Re: Il manque Kopete dans la liste

      Posté par (page perso) . Évalué à 2.

      J'ai la désagréable sensation que la compatibilité GTalk/Jabber semble quelque peu compromise... Je sais pas si vous avez essayé d'utiliser un compte GTalk sur Gaim, c'est pas très concluant.
      Alors, oui, on peut parler tranquillou, mais impossible d'utiliser des trucs simple de Jabber comme le changement de pseudo + message d'info sur ce qu'on est en train de faire. De plus l'affichage des infos est vraiment restreinte...

      J'ai comparé sur les deux vu que j'ai un compte Jabber et un compte GTalk.

      Vous en pensez quoi vous de cette compatibilité que Google avait pourtant annoncée??
      • [^] # Re: Il manque Kopete dans la liste

        Posté par . Évalué à 5.

        c'est pas une incompatibilité entre gtalk et gaim mais entre gaim et jabber.
        Attend gaim 2.0 avant de voir ce que fais gaim en fait vu qu'il va y avoit pleins de nouveaux trucs, dont le support de ces fonctions je suppose :)
        • [^] # Re: Il manque Kopete dans la liste

          Posté par . Évalué à 2.

          oui bon en fait jcrois que jdis nim car je lis trop vite : )

          tu voulais dire que le "jabber" gtalk n'implementait pas ces fonctions ?
        • [^] # Re: Il manque Kopete dans la liste

          Posté par . Évalué à 4.

          je pense pas que ce soit limité à gaim, avec kopete aussi il y a ce problème de non support des notifications de gtalk (frappe clavier,..). Et pour ce que j'en avais essayé psi également.
          • [^] # Re: Il manque Kopete dans la liste

            Posté par . Évalué à 7.

            Il y a (au moins) deux JEP de "notification d'évènement. Une de statut "historical" et une au statut draft (respectivement le 22 et la 85). Les clients historiques (psi, gaim, kopete par exemple) utilisent le 22, alors que les plus récents (gajim tout du moins) le 85.

            Peut-être gtalk utilise-t-il le 22... pour en être sûr, quelqu'un peut essayer gajim <-> gtalk ...
    • [^] # Re: Il manque Kopete dans la liste

      Posté par . Évalué à 4.

      > Sinon, il est vrai que Jingle-video n'existe pas encore, mais ça va suivre apres.

      En même temps, quand on voit Jingle-audio, on reconnait bien un SDP SIP à la sauce XML. La description d'une video se fera de la même façon.
  • # anglicisme

    Posté par . Évalué à 3.

    status ==> statut

    Merci.

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

    • [^] # Re: anglicisme

      Posté par . Évalué à 3.

      En même temps, il y a aussi la faute classique sensés -> censés, mais si on s'amusait à corriger toutes les fautes ...
      • [^] # Re: anglicisme

        Posté par . Évalué à 1.

        suffit de penser que meme si c'est cense c'est avec ...
      • [^] # Re: anglicisme

        Posté par . Évalué à -2.

        meme si c'est cense, c'est avec ...
  • # Centralise vs desentralise

    Posté par (page perso) . Évalué à 2.

    La complexité d'interface XMPP/protocole externe devrait donc être ramenée au niveau des passerelles (côté serveur), ce qui a toujours été la philosophie de Jabber.

    Ca c'est un truc que je ne comprends pas. On essaye le plus possible de tout decentraliser alors qu'au contraire Jabber (semi) centralise.

    La philosophie d'Internet (de TCP/IP) est de mettre l'intelligence au bord du reseau. On voit actuellement a quel point ces concepteurs avaient raison: on peut faire passer n'importe quel type d'information sur Internet, se sont les terminaux (PC) qui intepretent l'information et ca tombe bien car ils sont de plus en plus puissants pour un cout de plus en plus faible.
    Avec Jabber au contraire ce sont les serveurs qui ont de l'intelligence en permettant l'interconnexion avec d'autres reseaux.

    La recherche actuelle est tournee vers les systemes decentralises:
    http://pdos.csail.mit.edu/chord/#pubs
    http://research.microsoft.com/~antr/Pastry/pubs.htm
    http://ntrg.cs.tcd.ie/undergrad/4ba2.02-03/p9.html

    Je ne sais pas si Jabber a de l'avenir, mais en tout cas je suis plus partisant pour des solutions comme Gaim ou c'est le PC final qui contient l'intelligence et pas le serveur.
    • [^] # Re: Centralise vs desentralise

      Posté par . Évalué à 2.

      Je comprend pas bien ta remarque, Jabber est l'exemple type du système décentralisé, et si tu veux pousser l'idée jusqu'au bout tu installes un serveur jabber en local, et je comprend pas bien la comparaison avec Gaim ? Tu compares un protocol avec un client IM.
    • [^] # Re: Centralise vs desentralise

      Posté par . Évalué à 7.

      Serveur ne veut pas dire centralise. Dans le cas de jabber, c'est même tout le contraire.

      Quelques serveurs officielements enregistrés:
      http://www.jabber.org/network/
      http://www.xmpp.net/

      Mais il y en a en réalité beaucoup plus que ça.

      Aprés, de mettre l'intelligence côté client ou serveur, c'est un autre débat, mais les serveurs jabbers sont effectivement décentralisé, et pas juste, que d'un point de vue technique ou géographique. Jabber ne dépend pas d'un pays ou d'une société, n'importe qui peut faire tourner un serveur jabber, que ce soit pour une utilisation publique ou privée.
      • [^] # Re: Centralise vs desentralise

        Posté par (page perso) . Évalué à 4.

        Aprés, de mettre l'intelligence côté client ou serveur, c'est un autre débat, mais les serveurs jabbers sont effectivement décentralisé

        Ba justement je parle de cet autre debat ! Mon post se refere a une citation: la gestion du multiprotocole se fait du cote serveur alors que pour moi cela devrait etre du cote client comme Gaim le fait. Je ne remet pas en cause le reste !
        • [^] # Re: Centralise vs desentralise

          Posté par . Évalué à 10.

          Non, le multiprotocole ca ne devrait pas exister, il faut se mettre d'accord sur un protocole commun.

          Tu imagines si on avait 50 versions de http ? Ce serait un beau bordel.

          Alors acceder a ICQ et compagnie depuis un compte Jabber c'est juste un truc "en bonus", pas une fonctionnalite cle de Jabber. Personne ne t'empeche d'utiliser Gaim pour acceder a ton compte jabber et tous tes autres protocoles.
          • [^] # Re: Centralise vs desentralise

            Posté par (page perso) . Évalué à 1.

            Non, le multiprotocole ca ne devrait pas exister

            On est tous d'accord avec ca. Le fait que ca existe et donc qu'il faut le supporter.

            Personne ne t'empeche d'utiliser Gaim pour acceder a ton compte jabber et tous tes autres protocoles.

            Je m'en doute, merci bien.

            Je le refait: je ne comprends pas la philosophie de Jabber qui est de gerer le multiprotocole cote serveur alors que la logique voudrait que cela soit gere du cote client. Le fait de gerer le multiprotocole cote serveur a aussi des impacts sur le protocole lui meme.
            • [^] # Re: Centralise vs desentralise

              Posté par (page perso) . Évalué à 6.

              Le fait de gerer le multiprotocole cote serveur a aussi des impacts sur le protocole lui meme.
              Beaucoup moins que si le client avait à le gérer lui même. Dans le cas actuel, les clients n'ont qu'à gérer un protocole de passerelle (qui peut servir pour autre chose que ICQ/MSN/AIM/Y!) plutôt que 50 protocoles d'IM différents..

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: Centralise vs desentralise

                Posté par (page perso) . Évalué à 1.

                "Le fait de gerer le multiprotocole cote serveur a aussi des impacts sur le protocole (+) Jabber lui meme."

                Beaucoup moins que si le client avait à le gérer lui même.

                Tu confonds: je parle de la definition du protocole Jabber.
            • [^] # Re: Centralise vs desentralise

              Posté par (page perso) . Évalué à 2.

              Non, le client ne doit gérer qu'un et un seul protocole...

              Regarde ton téléphone, tu ne lui demandes que de joindre tes correspondants... qu'ils soient en RTC, GSM, RNIS, MGCP, SIP et j'en passe !

              Regarde ta téloche : tu as une antenne RF, un boîtier TNT, un câble; une parabole, c'est un gros bordel !
              • [^] # Re: Centralise vs desentralise

                Posté par (page perso) . Évalué à 3.

                Regarde ton téléphone, tu ne lui demandes que de joindre tes correspondants... qu'ils soient en RTC, GSM, RNIS, MGCP, SIP et j'en passe !

                Ah? Je croyais que mon téléphone parlait :
                - Pour la com' : GSM, GPRS, EDGE, UMTS release3, UMTS Release 4, et les prochains supporteront UMTS release 5 (HSPDA).
                - Pour l'affichage : WAP, HTML, Java.

                Rien que pour joindre mes correspondants, j'ai 5 normes, et pour afficher des choses au moins 3 normes.

                Mauvais exemple donc, ou exemple contre ce que tu affirmes : le client supporte souvent plusieurs normes, que ce soit un telephone ou un PC.
                • [^] # Re: Centralise vs desentralise

                  Posté par . Évalué à 4.

                  Mauvais exemple donc

                  Je pense que tu as détourné l'exemple original.

                  Pour le téléphone, il te suffit d'une seul norme pour pouvoir l'utiliser. J'ai un vieux téléphone portable qui ne connaît que le GSM. Pourtant, si j'ai envie de t'appeler, je pourrai.

                  Ce n'est pas le cas de ta télévision. Je n'ai pas de décodeur canal+, je ne peux pas regarder cette chaîne ; je n'ai pas de boitier TNT, je n'ai pas accès aux chaînes offertes ; je n'ai pas de parabole, je n'ai pas accès aux chaînes diffusées par satellites.

                  Quoi qu'il en soit concernant la pertinence de cet exemple, il est évidemment mieux pour tout le monde qu'un seul protocole d'IM puisse s'imposer. Après tout, pour les mails, il n'y a que SMTP pour l'acheminement des mails. Pour le web, il n'y a que l'HTTP.

                  À part pour les sociétés qui ont des parts importantes de marché, comme Microsoft, tout le monde a intérêt à se tourner vers un protocole ouvert et normalisé.

                  Ce sont pour ces raisons que je pense de manière raisonnable qu'un protocole comme celui de Jabber finira par s'imposer, malgré l'hégémonie de MSN, surtout en Europe.
                  • [^] # Re: Centralise vs desentralise

                    Posté par (page perso) . Évalué à 0.

                    On va continuer l'exemple du telephone mobile :
                    Si ton telephone est uniquement GSM comme tu le dis, ben... si tu es dans une zone non couverte par le GSM mais seulement par l'UMTS (hypothetique en FRance, mais reel ailleurs), tu ne peux pas me telephoner avec ton téléphone!!!
                    Quel que soit le sens dont tu tourneras ton argument, il se retournera contre toi : un telephone ne pourra pas parler a une antenne ne parlant pas la meme lanque, c'est un fait.

                    En fait tu confonds deux choses : l'accès au reseau (GSM, UMTS) et l'accès a une personne pas sur le meme reseau (RTC, SIP)
                    Si on reviens a Jabber, ne confond pas l'accès au reseau Jabber ou MSN, et l'interopérabilité entre les reseau Jabber et MSN.
                    On a alors plusieurs solutions pour cette interoperabilité : soit un seul protocole (mais inimaginable), soit plusieurs protocoles dans le messenger, soit des passerelles.

                    Jabber a fait le choix des passerelles (comme le telephone entre Fixe et Mobile), Gaim a fait le choix du multiportocole (comme le telehone mobile entre GSM et UMTS), je pense que comme pour le telephone c'est une addition des deux qui fonctionnera.

                    PS : en terme d'opérabilité dans le telephone mobile, desolé, j'utilise pas les passerelles, pour telephoner a un fixe j'utilise un fixe a coté de moi, comme quoi, ton exemple de telephone n'est vraiment pas bon, car en general on utilise au moins deux protocole auniveau du client (GSM, et RTC)... A moins que tu n'es pas d'abonnement fixe et que tu utilise qu'un telephone ;-)
                    • [^] # Re: Centralise vs desentralise

                      Posté par . Évalué à 8.

                      Il a raison, tu es encore à côté de la plaque là.
                      Il est évident qu'on considère un "client" (ici le téléphone) se connectant à un "serveur" (l'antenne) parlant le même protocole.

                      Il n'est pas question de pouvoir téléphoner *de* n'importe où, mais bien *vers* n'importe où en ne "connaissant" qu'un unique protocole de communication, le GSM par exemple.


                      Avec les IM, si tu utilises jabber par exemple, il est *évident* que tu ne te connecteras pas à un serveur MSN. Mais là différence est là : tu es connecté au réseau parce que (intelligemment !) tu te connectes à un serveur jabber, et grâce aux passerelles : tu peux communiquer avec des gens sous Yahoo par exemple, ne connaissant qu'un unique protocole, et te connectant à quelqu'un qui te comprend.
                      La réciproque est fausse, si tu utilises ICQ, tu peux te gratter pour causer à quelqu'un sous jabber, MSN, Yahoo...


                      En bref, il te dit qu'avec les téléphones portables tu n'as *pas* besoin de te connecter à tout les réseaux pour communiquer sur tout les réseaux, un seul suffit et ceci parce qu'il y a des "passerelles" entre ces réseaux.
                      Et que pour les IM, c'est l'inverse, mais que jabber lui te permet de fonctionner de façon similaire, certes grâce à une sorte de bidouille, car il te faut quand même un compte sur les autres réseaux.


                      C'est, je le crains, toi qui confond l'accès à un réseau et l'accès à une autre personne sur un autre réseau...


                      Et euh perso, je n'ai pas de téléphone fixe, et pour appeler des gens, je suis 100% GSM de mon côté de la ligne, quel que soit le destinataire, et je ne m'en porte pas plus mal...
                      Et euh perso, je n'ai que jabber (psi + passerelles sur jabber.org.uk), et pour parler à des gens, je suis 100% jabber de mon côté de la ligne, quel que soit le destinataire, et je ne m'en porte pas plus mal...


                      Yth.
        • [^] # Re: Centralise vs desentralise

          Posté par . Évalué à 10.

          Et en fait il y a pas mal d'avantages à pouvoir faire ce "multi-protocole" via les passerelles sur le serveur : on profite des avantages énormes de jabber sur tout les autres.
          Par exemple, tu es en entreprise, ou en résidence estudiantine, il peut y avoir un serveur jabber local, permettant les communications locales directement sans pomper le tuyau vers internet, et la politique réseau est restrictive vers le net, ce qui t'empèche de te connecter directement sur tout tes protocoles exotiques d'IM que tu affectionnes.

          Il suffit que l'admin laisse uniquement le serveur jabber accéder au net sans limitations pour que tu puisses multi-protocoler grâce à lui, et sans qu'il ait besoin d'installer les passerelles dessus, puisque tu peux en étant connecté sur un serveur, utiliser via lui les passerelles installées sur un autre !

          De plus, comme pour par exemple MSN, tout n'est pas géré, en particulier le transfert de vir... fichiers, tu protège le réseau interne des nuées de vers, chevaux de troie, virus et compagnie qui se propagent allègrement sur ce merveilleux incub... réseau.

          Donc dire comme ça "faut mettre tout sur le client et rien sur le serveur" c'est pas forcément super subtil, la réalité est (toujours) plus complexe et riche, et chiante, et frustrante, et passionnante, et désolante, et... Rhaaa !


          Yth.
          • [^] # Re: Centralise vs desentralise

            Posté par (page perso) . Évalué à 10.

            perso j'aime bien l'idée d'avoir un logiciel qui met pas 100 ans à s'ouvrir sur un ordinateur de poche... Alors qu'un serveur lui bah il peut etre aussi gros qu'on veut.
    • [^] # Re: Centralise vs desentralise

      Posté par (page perso) . Évalué à 5.

      >Je ne sais pas si Jabber a de l'avenir, mais en tout cas je suis plus partisant pour des solutions comme Gaim ou c'est le PC final qui contient l'intelligence et pas le serveur.

      Je crois que tu fais un petit amalgame.

      Comme le montre les autres réponses à ton commentaire. les serveurs Jabber sont décentralisés justement. Contrairement à ICQ ou MSN, tu peux te connecter au serveur que tu préfère, celui de ton LUG, ton propre serveur, etc. du moment que ce serveur est connecté au autres tu "vois" le monde entier ;-).

      Gaim n'embarque pas plus d'intelligence que n'importe quel client Jabber, si ce n'est que c'est un client multi-protocole. On peut rapprocher Gaim des navigateurs modernes qui savent faire du HTTP, du FTP et tous les trucs qu'on veut bien leur apprendre via les plugins and co.

      Quand au fait qu'il y ait des serveurs pour les com. de type messagerie instantanée, je pense que c'est surtout parceque cela permet justement le instantané. En effet, en terme de IM/Chat réellement décentralisé (P2P) on peut citer MyJXTA2[1] qui est un vrai chat P2P. Le problème (à ce que j'en ai vu lors de mes petits tests) c'est que la détection des autres manque de réactivité. Mais sinon, c'est très séduisant.

      [1] http://myjxta2.jxta.org/
    • [^] # Re: Centralise vs desentralise

      Posté par . Évalué à 10.

      La philosophie d'Internet (de TCP/IP) est de mettre l'intelligence au bord du reseau. On voit actuellement a quel point ces concepteurs avaient raison: on peut faire passer n'importe quel type d'information sur Internet, se sont les terminaux (PC) qui intepretent l'information et ca tombe bien car ils sont de plus en plus puissants pour un cout de plus en plus faible.
      Avec Jabber au contraire ce sont les serveurs qui ont de l'intelligence en permettant l'interconnexion avec d'autres reseaux.


      Au niveau de la philosophie d'internet, je ne suis pas tout à fait d'accord. En fait, effectivement, la philosophie d'Internet est de mettre l'intelligence au bord du réseau, c'est à dire de décentraliser. Cependant, quand tu regardes l'Internet actuel, tu comprends vite que le bord du réseau n'est pas l'utilisateur final mais le LAN. Chaque sous-réseau peut avoir son propre serveur Web, son propre serveur mail, son propre DNS, etc. En revanche, au niveau du client final, le but est qu'il reste le plus simple possible. On le voit bien au niveau du web, un client web n'est qu'une interface pour récupérer des informations qui sont générées au niveau du serveur. On appelle d'ailleurs ça un client léger.

      Un système de messagerie instantanée complètement P2P ne serait pas forcément dénué d'intérêt mais aurait quand même beaucoup d'inconvénients. Ta liste de contacts serait locale (donc si tu changes de machine tu ne la retrouves pas), tu devrais t'authentifier auprès de tous tes contacts plutôt qu'auprès d'un serveur, etc.
    • [^] # Re: Centralise vs desentralise

      Posté par (page perso) . Évalué à 4.

      même si j'étais pas d'accord avec toi ...
      merci pour ta remarque qui a donné suite à un débat vraiment très instructif ! sans aucun troll, et vraiment passionnant ...

      Je suis également un convaincu jabber, mais j'ai adoré le comparatif avec les gsm ... ça m'a expliqué pas mal de choses ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.