NaradaBrokering

par BaroqueW et Xor

I. Pair-à-Pair et Grille

Au cours des dernières années, on a assisté au développement de deux systèmes d’applications réparties : le système pair-à-pair et le système de type grille. Ces deux systèmes ont des avantages complémentaires.

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.

II. Principes du NaradaBrokering

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 NAT, DHCP et autres pare-feu 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.

III. Topologie du réseau utilisé

Le réseau lié au NaradaBrokering est considéré comme étant constitué de brokers coopérants les un 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.

La figure 1 montre un exemple de réseau utilisant NaradaBrokering. Les SC-i sont des exemples de sous-ensembles (super cluster) et SSC-A est un ensemble regroupant ces sous-ensembles (super-super-cluster). Chacun des SC-i a d’ailleurs des sous-sous-ensembles a regroupant plusieurs brokers et services auxquels sont connectés plusieurs clients. On voit également les échanges de message entre brokers et services ainsi que les messages entre brokers pour pouvoir constamment répondre au mieux attentes du client connecté au broker 12.

Figure 1 : Exemple de réseau NaradaBrokering
 

IV. Interaction avec JXTA

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.

Figure 2 : Interaction JXTA et NaradaBrokering

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.

V. Sécurité et développements possibles

• Sécurité

Etant donné que les messages au sein d’un système NaradaBrokering peuvent traverser des nœuds plus ou moins sécurisés, il est nécessaire de mettre en place une infrastructure reposant sur des niveaux de sécurité pour les messages. La gestion de la sécurité dans NaradaBrokering a pour intention de garantir ou permettre :

• l’authentification des utilisateurs
• leur autorisation
• la gestion de signatures digitales, et le partage de clés
• l’intégrité des données
• l’indépendance vis-à-vis du protocole de communication utilisé

• Développements possibles

Ainsi, NaradaBrokering est une infrastructure reposant sur l’échange de messages, qui paraît appropriée aux Grilles pair-à-pair. Comme il existe de plus de nombreux matching engines, cela favorise les interactions possibles, et enrichit les mécanismes de découvertes. C’est notamment le cas avec un moteur supportant le XML.
L’objectif est également  à terme de supporter les bases de données Native XML (Xindice et eXist).
Un travail en collaboration avec Gnutella est également en cours, dans le cadre d’une fédération de systèmes pair-à-pair, et de standardisation des mécanismes de recherche, requêtes, et réponses.

VI. Bibliographie

• http://www.naradabrokering.org/ : le site officiel du projet
• Towards Enabling Peer-to-Peer Grids : Journal of Concurrency and Computation: Practice & Experience. ACM JavaGrande ISCOPE Special Issue.Volume 17, Issue 7-8 , Pages 1109 - 1131.
  Geoffrey Fox, Shrideep Pallickara and  Xi Rao.
• NaradaBrokering: A Middleware Framework and Architecture for Enabling Durable Peer-to-Peer Grids. Proceedings of ACM/IFIP/USENIX International Middleware Conference Middleware-2003. pp 41-61.
  Shrideep Pallickara and Geoffrey Fox
• Support for Peer-to-Peer Interactions in Web Brokering Systems.  ACM Ubiquity. Volume3 Issue 15. May 2002. 
  Geoffrey Fox and Shrideep Pallickara
• NaradaBrokering: Towards P2P Grids. Talk given to Beihang University Multimedia Group, Beijing.
  Shrideep Pallickara.
• NaradaBrokering: A Middleware Framework and Architecture for Enabling Durable Peer-to-Peer Grids. ACM/IFIP/USENIX International Middleware Conference Middleware-2003.
  Shrideep Pallickara and  Geoffrey Fox

Cette création est mise à disposition sous un contrat Creative Commons.

Webmaster : Xor
Site optimisé pour Firefox >2, résolution 1280x1024 :)