Passer au contenu

Architectures peer to peer : jusqu’au bout de la décentralisation

Les architectures peer to peer sous-tendent une décentralisation maximale d’applications essentiellement réparties sur des PC, dont les ressources en sommeil sont ainsi exploitées.

Après FTP ou Telnet, vint le web. Après lui, viendra le peer to peer – P2P ou poste à poste. Tel est le discours tenu par les aficionados les plus enthousiastes de ce mode d’interaction et de partage de ressources ” d’égal à égal ” entre systèmes. D’autres verront simplement dans ce phénomène un nouvel épisode du mouvement de balancier entre centralisation et distribution des ressources et des traitements. Le fait est que ces nouvelles architectures – popularisées par des applications grand public d’échange de fichiers musicaux, comme Napster ou Gnutella – répondent élégamment à des questions jusqu’alors laissées en plan par les approches traditionnelles. A tel point que de jeunes fournisseurs d’applications professionnelles de travail en groupe (Groove, Proksim) ou de commerce électronique (Lightshare ou FirstPeer) font du P2P leur religion. D’autres, tels Network Associates, NextPage ou Gnesilent, distillent le concept dans des fonctions plus classiques pour en optimiser l’efficacité. Tandis que de jeunes pousses cherchent à revendre aux entreprises en mal de gigaflops (*) la puissance de calcul de leurs PC reliés à l’internet.

Web, messagerie et FTP sont sur la touche

Malgré la grande disparité de leurs principes et objectifs, les applications P2P présentent plusieurs points communs : exploitation systématique des ressources des PC, autonomie relative ou totale par rapport aux serveurs, et procédés d’adressage contournant le système DNS (Domain Name Server). De facto, les autres applications de l’internet (web, messagerie, FTP) sont sur la touche. Ce qui requiert l’installation, sur chaque PC, d’un logiciel client spécifique.” Utiliser la puissance endormie de l’internet. ” Tel est le slogan de la société Distributed Science. De fait, l’une des caractéristiques essentielles des applications P2P réside dans leur capacité à exploiter les ressources situées ” au bord ” de l’internet – les PC, mais aussi leurs utilisateurs. Le sport à la mode consistant à comptabiliser le poids de ces ressources. Même sur un intranet, les unités de mesure atteignent vite le téraflop ou le téraoctet. A la clé, des économies pour les entreprises qui éviteront d’acheter des serveurs. Les applications seront également plus efficaces, voire moins vulnérables, car non dépendantes du bon fonctionnement de serveurs. Mais le P2P représente aussi du pain bénit pour Intel, toujours à l’affût d’un moyen de justifier sa course à la puissance. En outre, il va à l’encontre du concept de client léger et de la tendance à une certaine recentralisation. Ce qui ferait plutôt l’affaire d’un certain Microsoft. Outre les processeurs et la mémoire, les ressources humaines sont, elles aussi, mises à contribution. Essentiellement par une administration déléguée aux utilisateurs. Mais ceux-ci peuvent aussi se transformer en commerciaux – lorsque Distributed Science leur verse une commission pour tout adhérent parrainé, par exemple.Qui dit P2P dit aussi autonomie des PC par rapport à des serveurs dont le rôle s’estompe, sans forcément disparaître. Ainsi, avec les applications scientifiques, les PC dialoguent encore avec un serveur qui découpe les données à traiter, les leur envoie – éventuellement accompagnées des programmes à exécuter -, puis récupère et consolide les résultats. Le reste du temps, ils réalisent dans leur coin les calculs demandés. Dans le cas d’applications non scientifiques, un dialogue direct s’instaure entre les postes, tour à tour serveurs ou clients. Soit dit en passant, ce mode de communication symétrique s’accommode mal des connexions souvent asymétriques des postes clients. Avec certaines applications, comme Napster ou Groove, un serveur initialise le dialogue. Une fois celui-ci établi, les PC se transmettent directement des fichiers, des flux, des pointeurs ou des requêtes. Pour les applications dénuées de serveur, le dialogue doit être initialisé par les PC eux-mêmes. Ceux-ci propagent alors de proche en proche des requêtes, qui correspondent, par exemple, à la recherche d’un contenu répondant à certains critères.

Des adresses IP différentes à chaque connexion

Le dialogue entre PC s’appuie sur un système d’adressage qui ne peut pas être basé sur DNS. Les adresses IP des postes clients sont en effet généralement allouées dynamiquement, et donc différentes à chaque connexion. De plus, l’application doit avoir une vision du statut des PC – connecté ou déconnecté. Pour résumer, les applications P2P sont comme des grat- te-ciel construits sur des sables mouvants. L’obstacle est aisément contourné quand un serveur – dont l’adresse IP est fixe et connue – établit le dialogue. Dans ce cas, un PC qui se connecte lui signale immédiatement sa présence et lui envoie sa requête. Parce que ce serveur tient à jour un annuaire des utilisateurs et des fichiers et autres contenus qu’ils hébergent, il peut retourner la liste des PC disponibles et est en mesure de répondre à la requête.Mais que se passe-t-il en l’absence de serveur ? Sur un intranet, dont le plan d’adressage privé permet d’allouer des adresses IP fixes aux PC, ceux-ci peuvent héberger un annuaire distribué. Mais, sur l’internet, comment un PC peut-il entrer dans la toile que tisse une application P2P si les n?”uds n’ont pratiquement jamais d’adresse IP propre ? Lorsqu’il veut se connecter, l’utilisateur doit en fait spécifier l’adresse IP d’un PC déjà connecté à l’application – débusquée, par exemple, sur un moteur de recherche, qui scrute l’internet en quête d’autres utilisateurs de l’application. Ce processus est moins aléatoire lorsque les connexions des PC sont permanentes, et, donc, les adresses fixes. Au-dessus de l’Internet Protocol, le dialogue entre clients ou avec le serveur est pris en charge par des protocoles souvent propriétaires. Parfois, ils sont bâtis sur des standards. Groove Networks utilise, par exemple, le modèle COM de Microsoft pour transporter des données encapsulées dans des messages XML, et le protocole XML-RPC pour déclencher des traitements. HTTP et FTP sont, eux, mis à profit pour mettre à jour les composants. De son côté, Endeavors s’appuie sur un serveur HTTP Apache installé sur chaque poste. Tandis que l’environnement de développement d’applications P2P, de Proksim, sous-tend une technologie propriétaire, que l’éditeur décrit comme un mélange d’architectures d’objets distribués – Corba, DCOM, RMI (Remote Method Invocation), par exemple – et de middlewares asynchrones, tel MQ-Series. En outre, toutes les applications P2P professionnelles chiffrent les flux. Mais, là encore, par le biais d’algorithmes variés.Car le P2P manque cruellement de standards. Leur définition représente l’un des objectifs du Peer to Peer Working Group. Créé à l’initiative d’Intel, ce dernier réunit aujourd’hui de nombreux acteurs, dont Groove, Proksim, Distributed Science et Endeavors, mais aussi de grands noms, comme IBM et HP.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Lévy-Abégnoli