NaradaBrokering

Les systèmes pair-à-pair ont une architecture très flexible reliant des pairs volontaires se trouvant à la bordure des réseaux. Les pairs sont alors reliés dans des réseaux correspondant plutôt à des réseaux ad hoc, c’est-à-dire tolérant aux déconnexions et aussi aux fautes. Ces systèmes sont davantage orientés vers le partage de fichiers et permettent aux pairs de rejoindre des groupes, émettre des requêtes, découvrir des ressources et signaler leurs intérêts particuliers pour certaines ressources.

Les systèmes de grille sont eux davantage orientés vers le partage de temps de travail. Ces réseaux sont en général robustes car fixes. Ils passent donc plutôt bien à l’échelle. En outre ces réseaux sont généralement soumis à de fortes contraintes de sécurité puisqu’ils travaillent souvent pour de projets industriels et/ou sensibles. En revanche le modèle de grille, même s’il est tolérant aux fautes, s’appuie davantage sur une certaine stabilité du réseau, une absence de nœuds opportunistes (leechers) et plus généralement, on peut dire que dans ce modèle, la volonté des nœuds et leur singularité ne sont pas vraiment des éléments clés.

La grande idée du NaradaBrokering va donc être de réunir les avantages de ces deux systèmes pour offrir aux utilisateurs un réseau de grande qualité. Pour intégrer le meilleur de ces deux modèles, le NaradaBrokering utilise des techniques tirées des objets distribués, des services web et, ce qui nous intéresse tout particulièrement ici, des intergiciels orientés message.

L’architecture utilisée ici est une architecture de réseaux locaux de pairs organisés à grande échelle par un réseau cœur. Pour l’accès aux services on introduit alors des « brokers ». C’est sur cette partie du réseau que vont principalement être utilisés les intergiciels orientés message. Ces brokers sont envisagés comme étant le plus petit élément de ce réseau. Ils ont pour mission de traiter et router intelligemment les messages. Plus particulièrement, voici les points clés de leur rôle :

• Ils doivent mettre en place un réseau qui puisse passer à l’échelle facilement, que l’on rajoute des nœuds ou des brokers.
• Ils doivent fournir un routage intelligent, notamment répartir la charge et minimiser le trafic tout en étant réactif aux déconnexions de certains nœuds, aux pannes réseaux etc. Il faut aussi que le système sache s’affranchir des NATs, DHCP et autres pare-feux qui compliquent souvent la tâche aux applications orientées réseau.
• Ils doivent fournir de la fiabilité lors des envois, ce qui n’est pas toujours le cas pour les systèmes de pair-à-pair.
• Les brokers doivent tolérer les protocoles de pair-à-pair qui ont souvent déjà leurs propres méthodes d’accès aux services (requêtes, etc.).
• Il faut également que ce réseau soit compatible avec le large panel de systèmes orientés messages déjà en place (des systèmes de type publish/suscribe tels que JMS et JXTA mais aussi MSMQ et MQSeries) ainsi qu’avec les différents protocoles réseau qui pourraient être utilisés en pair-à-pair (TCP/IP, UDP, RTP, RMI, XML/SOAP). La compatibilité désirée pousse aussi le réseau à devoir s’adapter à des communications asynchrones mais aussi synchrones. Enfin, le système du NaradaBrokering doit pouvoir être utilisé sur un grand nombre de plates-formes différentes (du nœud mobile à la station de travail fixe).
• Enfin, ce réseau devra être sécurisé et pouvoir surveiller les performances du réseau, l’activité des différents nœuds afin de pouvoir maintenir un certain niveau de qualité de service dans le réseau.

Le réseau lié au NaradaBrokering est considéré comme étant constitué de brokers coopérants les uns avec les autres, que ceux-ci soient situés sur des machines qui sont aussi de simples clients ou non.

Pour éviter d’avoir un réseau de brokers disparate et mal connecté, NaradaBrokering intègre un protocole de communication entre brokers chargé de gérer les liaisons entre brokers et de gérer l’ajout (ou le retrait) de brokers au réseau. L’organisation de ce réseau est faite de façon hiérarchique, chaque broker faisant partie d’un sous-ensemble, regroupé avec d’autres sous-ensembles en un autre ensemble, etc. Ces premiers sous-ensembles possèdent des brokers fortement interconnectés avec les autres sous-ensembles afin de garantir une liaison même en cas de panne. On a ainsi de petits réseaux connectés les uns aux autres. Ceci fait que lorsqu’on augmente la taille du réseau, le trafic augment de façon logarithmique et non exponentielle comme dans le cas des réseaux mal organisés ou désorganisés. NaradaBrokering introduit d’ailleurs des Brokers Network Maps (BNM) permettant d’assurer le routage intelligent évoqué plus haut.

JXTA est un projet Open Source dont le but est de proposer un ensemble de protocoles standards pour le modèle de communication pair-à-pair.

Le NaradaBrokering supporte les interactions avec le pair-à-pair, en fixant deux contraintes principales :

• Aucune modification n’est faite au niveau du noyau JXTA, et des protocoles associés. L’intégration se fera au niveau de la couche « rendez-vous ».
• Du point de vue des pairs, aucun changement n’est visible en ce qui concerne les interactions qu’ils pourraient avoir.

L’intégration de JXTA repose sur un modèle de proxy, ce dernier pouvant être vu comme une passerelle entre le système NaradaBrokering et JXTA, jouant en même temps le rôle d’un pair rendez-vous (sorte de super-pair), et un client NaradaBrokering. Du point de vue JXTA, NaradaBrokering peut être considéré comme un service, dont la découverte est automatique, grâce à l’intégration dans la couche rendez-vous. Du point de vue des pairs, l’interaction avec un proxy Narada-JXTA ou un pair rendez-vous est totalement invisible.

Le modèle d’interaction gravite donc autour de la couche rendez-vous : celle-ci traite les interactions placées en queue. Dans le cas de requêtes de recherche/découverte, ou de communication au sein d’un groupe de pairs, les interactions seront traitées à la fois par les pairs de rendez-vous JXTA, et les proxies Narada-JXTA. Lors de son initialisation en tant que client Narada, chaque proxy se voit assigner un identifiant unique. Il souscrit ensuite à un sujet l’identifiant comme proxy Narada-JXTA, ce qui permet au système de connaître tous les différents proxies présents.

D’autre part, en tant que pair rendez-vous, le proxy récupère certaines informations des interactions JXTA, telles que par exemple :

• les annonces des groupes de pairs
• les demandes d’intégration à ces groupes, et leurs réponses
• les messages envoyés à un groupe

Puis un événement correspondant aux informations récupérées est créé, ciblant des sujets spécifiques, pour un routage plus efficace.

• Pair-à-pair
• JXTA

• (en) Le site officiel du projet