Proposition d une grille d analyse pour la composition de systèmes P2P adaptés aux contextes applicatifs

Transcription

1 Institut Charles Delaunay (ICD) UMR 6279 École doctorale SSTO Proposition d une grille d analyse pour la composition de systèmes P2P adaptés aux contextes applicatifs THÈSE présentée et soutenue publiquement le 6 décembre 2012 pour l obtention du Doctorat de l Université de Technologie de Troyes (spécialité Réseaux, Connaissances et Organisations RACOR) par Frédéric Merle Composition du jury Président : M. Pascal Lorenz Professeur des Universités Rapporteurs : Mme Elena Mugellini Professeur des Universités M. Ahmed Serhrouchni Professeur des Unuversités Examinateurs : M. Aurélien Bénel Maître de Conférences M. Grégory Bonnet Maître de Conférences M. Guy Pujolle Professeur des Universités Directrice de thèse : Mlle Dominique Gaïti Professeur des Universités

2 Mis en page avec la classe thloria.

3 Remerciements Je tiens d abord à remercier ma directrice de thèse professeur Dominique Gaïti pour avoir crue en moi et m avoir soutenue pendant ces quatre longues années. Je remercie professeur Pascal Lorenz d avoir présidé mon jury de thèse ainsi que professeur Ahmed Serhrouchni et professeur Élena Mugellini d avoir accepter d être rapporteur de ma thèse ainsi que le professeur Guy Pujolle et les maitres de conférences Aurélien Bénel et Gregory Bonnet de m avoir fait l honneur de l examiner. Je voudrais aussi remercier l ensemble de mes amis et collègues que j ai rencontrés pendant ces années de doctorat et plus particulièrement Yann Barloy, Matthieu Tixier, Myriam Lewkowicz, Gergory Bonnet, Aurélien Bénel, Christophe Poirier, Caroline Serta, Isabelle Martin, Marie-Florence Reveneau et Tiffany Gaubert ainsi que tous les autres que j oublie. Je remercie aussi Loïc Corbasson et Thomas Raynal qui me soutiennent et subissent mon orthographe calamiteuse depuis de nombreuses années maintenant. Enfin, je souhaiterais remercier ma famille et plus particulièrement mes parents qui me soutienne et m encourage à aller toujours plus loin. i

4

5 TABLE DES MATIÈRES Table des figures Liste des tableaux xi xiii Chapitre 1 Le modèle P2P : une alternative au modèle Client/Serveur Les systèmes distribués Modèles de distribution Modèle Clients/Serveur Modèle P2P Portée de la distribution Réseau dédié Réseau préexistant Définition des systèmes P2P Développement des systèmes P2P Répondre à des besoins émergents Passage à l échelle Tolérance aux pannes Décentralisation Les premiers systèmes P2P Les premières applications Les systèmes théoriques Domaines d applications des systèmes P2P iii

6 Table des matières Middleware Système de recherche documentaire Système de stockage sécurisé Système de travail collaboratif Système de calculs distribués Système de diffusion de données Développement des systèmes P2P dans l industrie Google Microsoft Amazon Émergence du Cloud Computing Bilan de 12 années de développement des systèmes P2P Multiplication des systèmes Pour chaque compromis sur les performances Pour chaque contexte applicatif Limites des classifications proposées Conclusion Chapitre 2 Analyse fonctionnelle des systèmes P2P existants Principes d analyses : une division des systèmes en trois couches fonctionnelles Couche d adaptation du réseau hôte Couche d indexation des ressources Couche application Classification des différentes approches utilisées dans les systèmes P2P Couche d adaptation du réseau hôte Serveur d adressage Les overlays Couche d indexation Index global Index locaux Index partagés Index distribué Couche application Partage de données iv

7 Traitements distribués Conclusion Chapitre 3 Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Analyse des propriétés fonctionnelles et non fonctionnelles Couche application Le partage de données Contraintes de latence Absence de connaissances à priori sur les destinataires des données Distribution des traitements Contraintes au niveau du temps de calcul Taux de parallélisation du traitement élevé Grille d analyse de la couche application Couche d indexation Passage à l échelle Tolérance aux pannes Schéma de recherche Recherches exactes Recherches floues Résultat des recherches Complétude Tolérance aux erreurs Placement des métadonnées La confidentialité Nomadisme des ressources Coût de maintenance Grille d analyse de la couche d indexation Couche d adaptation du réseau hôte Passage à l échelle Tolérance aux pannes Découverte des pairs Par propriétés Par identifiant v

8 Table des matières Quantité de messages transmis Latence De la recherche De la transmission La non-imputabilité des actions Capacité de répudiation Obscurcissement Grille d analyse de la couche d adaptation du réseau hôte Interdépendance entre les approches Conclusion Chapitre 4 Deux études de cas pour évaluer notre grille d analyse Le cas d un système de fournisseur de services à l habitat Les systèmes de fournisseur de services à l habitat Les services à l habitat Home Area Networks Smart grids Différentes instanciations actuellement commercialisées en France Proposition d un modèle générique d un système de fournisseur de services à l habitat Le fournisseur de services Les sites Le client Conclusion sur l étude du cas d un fournisseur de services à l habitat Le cas des archives scientifiques Les archives scientifiques Objectifs de l archivage Conservation des documents numériques Accessibilité des documents numériques Théorie des trois âges Les archives courantes Les archives semi-courantes Les archives définitives vi

9 4.2.4 Le cahier de laboratoire numérique Archivage des documents numériques Outil de travail pour les chercheurs Les cahiers de laboratoire actuellement disponibles Conclusion sur l étude du cas des archives scientifiques Conclusion Chapitre 5 Proposition d un système P2P pour un fournisseur de services à l habitat Besoins spécifiques associés à un système pour un fournisseur de services à l habitat Besoins architecturaux Passage à l échelle Haute disponibilité Considération financières Besoins fonctionnels Gestion des communications de groupe Supervision Adéquation d un système P2P avec les besoins Étude des systèmes P2P existants répondant aux besoins fonctionnels Les systèmes de multicast applicatif en P2P Les systèmes de supervision en P2P Analyse de l adéquation des systèmes existants par rapport au cas d étude Proposition du système Définition des propriétés et contraintes à considérer Propriétés architecturales Propriétés liées aux besoins Utilisation de notre grille d analyse Couche application Couche d indexation Couche d adaptation du réseau hôte Vue d ensemble du système Validation du système proposé Support du passage à l échelle vii

10 Table des matières Tolérance aux pannes Latence des communications Quantité de messages transmis par les habitats Bilan de la comparaison Conclusion Chapitre 6 Proposition d un système P2P pour les archives scientifiques Besoins définis dans le cadre du projet sur les cahiers de laboratoire numérique Préservation des documents Système de gestion de révision Recherche documentaire Conservation des pratiques de travail Étude des systèmes P2P existants répondant aux besoins du projet Systèmes P2P de stockage sûr Système P2P de recherche documentaire Systèmes P2P de travail collaboratif Analyse de l adéquation des systèmes existants par rapport au cas d étude Proposition du système Définition des propriétés et contraintes à considérer Architecture adaptée à l organisation du travail des utilisateurs Gestion de tout type de document Sécurité du système Le partage documentaire Utilisation de notre grille d analyse Couche application Couche d indexation Couche d adaptation du réseau hôte Vue d ensemble du système proposé Comparaison avec d autres approches existantes Traitement des requêtes Nombre de pairs contactés viii

11 Quantité de données transmises Complexité des traitements Nombre minimum de pannes pouvant entrainer un résultat incomplet Taille de l index Bilan de la comparaison Conclusion Références 151 Annexes 165 États de l art spécifiques aux besoins des différents contextes applicatifs considérés Les systèmes de multicast applicatif en P2P Les approches par arbre Les approches mesh en premier Les approches arbre en premier Les approches par rumeur Comparaison des systèmes Les systèmes de supervision distribuée en P2P Les approches par arbre Les approches par rumeur Les approches hiérarchiques Comparaison des systèmes Systèmes P2P de stockage sûr OceanStore Glacier Total Recall Comparaison des systèmes Système P2P de recherche documentaire Approche par mots-clefs Attribution des mots-clefs Distribution de l index ix

12 Table des matières 3.7 Approche par similarité Réduction des espaces métriques Navigation dans les espaces métriques Comparaison des systèmes Systèmes P2P de travail collaboratif x

13 TABLE DES FIGURES 1.1 Classification des systèmes informatiques Différence au niveau du réseau hôte entre une grappe de calculs et un système P2P Segmentation des systèmes P2P en trois couches fonctionnelles Utilisation d un serveur d adressage pour l adaptation du réseau hôte. Chaque pair est connecté au serveur afin de localiser les autres pairs du système et créer des connexions ad hoc les uns avec les autres Représentation d un overlay. Chaque pair maintient un nombre limité de connexions avec d autres pairs du système afin de transmettre les messages de pair en pair jusqu à atteindre sa destination Organisation d un overlay hiérarchisé. Les pairs feuilles sont connectés à des super-pairs (représenté ici par des serveurs) qui sont eux-mêmes interconnectés les uns aux autres par un overlay. Ces deux niveau d overlay sont utilisés pour retrouver un pair particulier dans le système afin de créer une connexion directe avec lui pour s échanger des informations A) Représentation des liens courts entre les pairs dans un espace métrique utilisant une distance de Manhattan sur 2 dimensions. B) Représentation des liens longs d un pair sur cette espace métrique Répartition des liens du pair P 0 dans le système Chord Diffusion d une requête sur un overlay hiérarchisé utilisant un index partagé. Les super-pairs (en rouge) ne transmettent la requête qu aux autres super-pairs et aux pairs feuilles possédant le document recherché Répartition de l index entre les pairs en fonction de leur empreintes généré par SHA-1 dans le système Chord Distribution des fragments de données depuis un serveur vers les pairs afin qu ils exécutent les traitements sur ces données en parallèle xi

14 Table des figures 2.10 Exécution des traitements sur un flux de données pendant son acheminement de pair en pair depuis sa source jusqu à sa destination Modèle d architecture d un Home Area Network Modèle d architecture de service au sein de l habitat dans les Smart Grids Modèle conceptuel d architecture de fournisseur de services au sein de l habitat Représentation du fournisseur de services dans le modèle conceptuel représentation d un site dans le modèle conceptuel représentation des interactions de l utilisateurs avec les différents acteurs du modèle Modèle générique d architecture de système de fournisseur de services à l habitat Représentation du système avec les trois types d entités qui le compose Organisation de notre système P2P avec un espace métrique à deux dimensions basées sur la localisation géographique des habitats. Les super-pairs du systèmes qui composent le bus de services par des liens courts en noir et des liens longs en rouge. Les points verts sur l espace métrique qui sont reliés au centres de calculs correspondent aux coordonnées de leurs connexions dans l espace métrique Encodage et distribution des documents selon le modèle d Intermemory Résolution d une recherche de zone par un système P2P reposant sur la navigation dans un espace métrique Structure de notre index pour la recherche par mots-clefs L organisation et les interaction entre les trois index sans sémantique et un utilisateur Encodage et distribution des documents selon le modèle d Intermemory Recherche par mots-clefs sur un index distribué par documents Recherche par mots-clefs sur un index distribué par terme Résolution d une recherche de zone par un système P2P reposant sur la navigation dans un espace métrique xii

15 LISTE DES TABLEAUX 2.1 Exemples de systèmes P2P existant pour chaque combinaison d approches d adaptation du réseau hôte et d indexation Incompatibilités des besoins et contraintes dégagés pour la couche application Types d approches associées aux besoins et contraintes dégagés Incompatibilités des besoins et contraintes dégagés pour la couche application Types d approches associées aux besoins et contraintes dégagés Incompatibilités des besoins et contraintes dégages pour la couche application Types d approches associées aux besoins et contraintes dégages Grille d analyse des synergies entre les approches de la couche indexation et adaptation du réseau hôte. Les cases vides correspondent à des relations neutres Grille d analyse des synergies entre les approches de la couche d application et adaptation du réseau hôte. Les cases vides correspondent à des relations neutres récapitulatif des offres de services de gestion de l énergie au sein de l habitat en France Influence de l augmentation du nombre de clients et de services sur le système Présentation des différents événements pouvant affecter la disponibilité du système Comparaison des systèmes de multicast applicatif Comparaison des systèmes d agrégation Choix d une approche pour l indexation des habitats Choix d une approche pour l indexation des services Types d approches associées aux besoins et contraintes dégages Comparaison des performances obtenues par les trois approches considérées 119 xiii

16 Liste des tableaux 6.1 Comparaison des systèmes de stockage sûr Comparaison des systèmes de recherche documentaire par mots-clefs avec N le nombre de pairs, R le nombre de termes présent dans la requête, T D le nombre moyen de termes par documents et D T le nombre moyen de documents par terme Comparaison des systèmes de recherche documentaire par similarité Performances des approches possibles au niveau de la couche d indexation Types d approches associées aux besoins et contraintes dégages Performance des approches d adaptation du réseau hôte par rapport aux besoins du système Croissance de la taille de l index en fonction de l approche de distribution retenue Comparaison des performances de notre approche hybride par rapport aux approches par documents et par termes Comparaison des systèmes de multicast applicatif Comparaison des systèmes d agrégation Comparaison des systèmes de stockage sûr Comparaison des systèmes de recherche documentaire par similarité Comparaison des systèmes de recherche documentaire par mots-clefs avec N le nombre de pairs, R le nombre de termes présent dans la requête, T D le nombre moyen de termes par documents et D T le nombre moyen de documents par terme xiv

17 INTRODUCTION Avec la démocratisation de l Internet et le développement des systèmes distribué à très large échelle, le modèle pair-à-pair, ou P2P, s est imposé comme une alternative au modèle Clients/Serveur. En effet, le modèle P2P permet de répondre à des limites inhérentes au caractère centralisé du modèle Clients/Serveur, comme le support du passage à l échelle ou la tolérance aux pannes. Ainsi, depuis le début des années 2000, le développement de systèmes basés sur le modèle P2P a connu un essor très important, conduisant à la proposition de nombreux systèmes différents. Parmi ces systèmes, on peut distinguer deux grandes catégories, les systèmes génériques développés entre les années 2000 et 2005 et les systèmes spécifiquement développés pour répondre à des contextes applicatifs particuliers. Ces derniers correspondent principalement à des systèmes P2P génériques développés précédemment auxquels des optimisations ont été apportées pour répondre aux besoins spécifiques du contexte ciblé. Or une grande partie des optimisations proposées dans les systèmes développés depuis 2005 sont difficilement réutilisables en l état. En effet, ces optimisations sont généralement intégrées à un système générique afin de présenter un système complet adapté à un contexte applicatif. De ce fait, il est difficile de déterminer l utilisabilité d une optimisation en dehors du système spécifique dans laquelle elle a été développée. La question qui se pose est donc de trouver un moyen pour faciliter la réutilisabilité des nombreuses optimisations et concepts développés depuis les années 2000 afin de composer des systèmes P2P adaptés à des contextes applicatifs variés à partir de l existant. La solution à ce problème est d analyser cet existant afin d identifier les composants fondamentaux d un système P2P et ainsi de dégager les différentes approches qui ont été développées pour chacun de ces composants. Or, bien que de nombreux états de l art sur les systèmes P2P aient été proposés depuis 2005, ils se contentent de classer les systèmes en fonction d un nombre limité de propriétés macroscopiques. Si ces classifications permettent de différentier des types de systèmes P2P, elles ne sont pas assez fines pour mettre en évidence les ensembles de fonctionnalités qui les composent. 1

18 Liste des tableaux Fort de ce constat, nous proposons une nouvelle classification basée sur un découpage fonctionnel des systèmes P2P. En effet, en découpant ces systèmes en différents blocs fonctionnels communs à l ensemble des systèmes P2P existant, chacun de ces blocs devient indépendamment des autres. Cela permet de dégager les types d approches ayant été développés pour chacun de ces blocs fonctionnels, mais aussi de faciliter la réutilisation de l existant en combinant des approches de différents blocs. De même, pour chacune des approches dégagées pour chacun des blocs fonctionnels, il est possible d identifier les optimisations qui s y rapportent et ainsi de caractériser leur impact et les conditions dans lesquelles elles peuvent être réutilisées. Cette classification permet donc de représenter l existant plus finement que celles précédemment proposées de sorte à mettre en évidence des blocs fonctionnels réutilisable pour la conception de nouveaux systèmes P2P. Afin d exploiter les nouvelles possibilités qui ont été mises en évidence par notre classification, nous avons analysé les propriétés des approches que nous avons dégagées pour chacun des blocs fonctionnels qui composent un système P2P. À partir de cette analyse, nous arrivons à déterminer quelle composition d approches est la plus adaptée pour répondre à un ensemble de besoins donné. De même, si aucune solution existante ne permet de répondre à l ensemble des besoins, notre analyse permet de déterminer au niveau de quel bloc fonctionnel il faut développer une nouvelle approche et de faciliter son utilisation dans d autres systèmes P2P. Nous avons organisé cette nouvelle connaissance sous la forme d une grille d analyse afin de proposer un outil d aide à la conception de systèmes P2P qui puisse être utilisé même par quelqu un qui ne possèderait que peu de connaissances sur le domaine. Afin d évaluer la pertinence de notre grille d analyse, nous l utilisons pour proposer des systèmes P2P adaptés à deux contextes applicatifs distincts, un système de service à l habitat et un système d archivage scientifique. Ces deux contextes correspondent à des ensembles de besoins très différents et permettent de montrer les apports de notre approche. Ainsi, dans l un des cas, notre grille d analyse permet de mettre en évidence une solution précédemment développée pour un contexte applicatif très différent. Dans le deuxième cas, l utilisation de la grille d analyse permet d identifier un manque dans l existant et de proposer une solution simple et adaptée pour répondre aux besoins exprimés. Le premier chapitre de cette thèse est consacré à une présentation des systèmes P2P et d une vue d ensemble des travaux effectués dans le domaine depuis le début des années Dans le deuxième chapitre, nous présentons l analyse fonctionnelle des systèmes P2P existants et la classification qui en découle. Le chapitre 3 présente notre grille d analyse d aide à la composition de systèmes P2P basée sur l étude des propriétés des différentes approches dégagées dans le chapitre précédent. Dans le chapitre 4, nous présentons les deux contextes applicatifs sur lesquels nous avons testé notre grille d analyse, à savoir : les services à l habitat et les archives scientifiques. Dans le chapitre 5, nous présentons l utilisation de notre grille d analyse pour le cas du système de service à l habitat, avec une description et une analyse des performances du système que nous avons obtenu. 2

19 Enfin, le chapitre 6 est consacré à l étude relative au cas des archives scientifiques, avec l utilisation de notre grille d analyse, la présentation du système obtenu et l évaluation de ses performances. 3

20

21 CHAPITRE 1 LE MODÈLE P2P : UNE ALTERNATIVE AU MODÈLE CLIENT/SERVEUR Dans ce chapitre, nous présentons le modèle pair à pair, aussi appelé modèle P2P, et ses spécificités par rapport aux autres modèles de systèmes distribués. Après avoir défini les propriétés fondamentales d un système P2P, nous présentons d un point de vue historique le développement de ces systèmes au cours des douze dernières années. Cette présentation regroupe les premiers travaux effectués sur le domaine ainsi que les différents contextes applicatifs dans lesquels ils ont été utilisés et les projets industriels qui en ont découlé. Enfin, nous finirons ce chapitre sur une analyse critique de cet existant et principalement sur le manque de rationalisation du domaine, rendant difficilement exploitable l abondante production scientifique de ces douze dernières années. 1.1 Les systèmes distribués On distingue deux grands types de systèmes informatiques, les systèmes centralisés et les systèmes distribués (Fig. 1.1) [21]. Les premiers correspondent au cas où l ensemble des traitements et données nécessaire à la réalisation d un service est effectué sur la machine utilisateur elle-même. Pour les systèmes distribués, tout ou partie de ces traitements et données sont déportés sur une ou plusieurs machines distantes. Nous ne nous intéresserons dans ces travaux qu à ce dernier type de système. Parmi les systèmes distribués, il existe plusieurs sous-types de système que l on peut distinguer en fonctions de certaines spécificités. Nous considérerons ici deux de ces spécificités : le modèle de distribution et la portée de cette distribution. En effet, ces deux spécificités permettent de distinguer les principales approches de construction d un système distribué existant. 5

22 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Figure 1.1 Classification des systèmes informatiques Modèles de distribution Le modèle de distribution correspond à la façon dont sont répartis les données et traitements nécessaires au système entre les différents acteurs qui le composent. Nous distinguerons ainsi deux modèles, le modèle Clients/Serveur et le modèle P2P (Fig. 1.1) Modèle Clients/Serveur Paradoxalement, ce modèle, qui est le plus répandu, correspond aussi à un cas limite des systèmes distribués. En effet, dans un modèle Clients/Serveur, tous les données et traitements nécessaires au système sont centralisés au niveau d une machine distante appelée serveur. Les ressources des machines utilisateurs, que l on appelle client, ne sont alors utilisées que pour interroger le serveur et afficher les réponses qu il retourne. Le principal avantage de ce modèle est sa simplicité. En effet, regrouper l intégralité des données et traitements sur une même machine, facilite l implémentation de nouveaux services. De même, la gestion du système se limite uniquement à la gestion du serveur, son possesseur ayant alors tout contrôle sur le système [46]. À l inverse, ce modèle est limité par cette même centralisation des ressources [150]. En effet, le serveur devient un point unique de rupture pour le système dans le sens où si le serveur devient indisponible, le service n est plus disponible pour les clients. De même, le serveur ayant des ressources limitées, le nombre de clients pouvant simultanément accéder au service est lui-même limité. Ce modèle ne supporte donc pas le passage à l échelle en nombre de clients Modèle P2P Le modèle pair-à-pair correspond à la mutualisation des données et/ou des capacités de traitement entre l ensemble des participants du système. Ainsi, chaque machine qui participe au système est à la fois client et serveur de celui-ci. 6

23 1.1. Les systèmes distribués Cette mutualisation des ressources des participants permet de répondre aux limites du modèle Clients/Serveur [150] dans le sens où il supporte l augmentation du nombre d utilisateurs. En effet, chaque nouvel utilisateur du système apporte aussi des ressources pour le faire fonctionner. De même, ce modèle ne possède pas de point unique de rupture, car le départ d un pair, quel qu il soit, ne remet pas en cause le fonctionnement du système dans son ensemble. Ce modèle est en revanche limité par sa complexité. En effet, les données et/ou capacités de traitement étant distribuées entre les participants, il est difficile de gérer leur utilisation. De plus, pour mettre en œuvre un service, chaque pair doit trouver les ressources nécessaires à sa réalisation sur l ensemble du système Portée de la distribution Pour qu un système distribué fonctionne, il faut que les machines qui y participent puissent communiquer. Ainsi, ces dernières doivent être interconnectées par un réseau commun. La nature de ce réseau influence fortement les caractéristiques du système distribué. On peut distinguer deux types de réseaux, les réseaux dédiés au système et les réseaux préexistants [57](Fig. 1.2). Figure 1.2 Différence au niveau du réseau hôte entre une grappe de calculs et un système P2P Réseau dédié Ce cas correspond à un réseau qui a été spécialement conçu pour permettre aux participant du système de communiquer entre eux. L infrastructure réseau est donc définie pour répondre à l ensemble des besoins de communication des machines participants au système distribué. De plus, seules ces machines sont reliées à ce réseau. 7

24 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur L avantage de cette approche est d avoir une infrastructure de communication totalement adaptée au système, que ce soit en terme de dimensionnement, de performances ou de fonctionnalités. Elle est donc principalement utilisée pour créer des grappes de calcul [57] où la performance est un enjeu prédominant. En revanche, cette approche est très onéreuse, car elle nécessite l utilisation d une infrastructure dédiée. De plus, cette même infrastructure détermine le dimensionnement du système, ne pouvant accueillir qu un nombre limité de machines Réseau préexistant Cette approche consiste à utiliser un réseau auquel toutes les machines sont préalablement connectées pour assurer les communications nécessaires au système distribué, par exemple le réseau internet [57]. Le principal avantage de cette méthode est son coût quasi nul, aucun ajout matériel à l infrastructure réseau préexistante n étant nécessaire. De plus, contrairement à l approche précédente, il n y a pas de limites imposées par le réseau sur le nombre de machines pouvant participer au système. En revanche, le réseau utilisé ne comprend pas uniquement des machines participant au système. Il est donc nécessaire de mettre en place un mécanisme permettant aux machines participant au système de se trouver les unes les autres sur le réseau. De plus, contrairement à un réseau dédié, le réseau utilisé ne fait pas à proprement parler du système lui-même. Ce dernier ne peut donc pas agir sur ses performances et doit s adapter à ce réseau pour fonctionner Définition des systèmes P2P En étudiant les différents types de systèmes distribués existants, une question qui se pose est de définir ce qu est un système P2P. En effet, si le modèle de distribution est important, la portée de cette distribution semble aussi impactante. En effet, une grappe de calcul peut être définie comme un système basée sur le modèle P2P reposant sur un réseau dédié. Ainsi, une grappe de calcul est elle un système P2P ou un type de système totalement différent? Pour répondre à cette question, il est donc nécessaire de définir ce qu est un système P2P. Il existe un grand nombre de définitions différentes des systèmes P2P, chacune se focalisant sur un aspect particulier de ce type de système [32]. Ainsi, aucune des définitions précédemment proposées ne permet de prendre en compte l intégralité des systèmes existants. Par exemple, Steinmetz, dans [149] donne la définition suivante : [a Peer-to-Peer system is] a self-organizing system of equal, autonomous entities (peers) [which] aims for the shared usage of distributed resources in a networked environment avoiding central services. 8

25 1.2. Développement des systèmes P2P Le problème de cette définition est qu elle implique que tous les pairs sont égaux, ce qui exclut un grand nombre de systèmes P2P, à commencer par Napster ou Gnutella 0.6 [55]. Il en va de même pour la définition proposée par Androutselis-Theotokis dans [16] : Peer-to-peer systems are distributed systems consisting of interconnected nodes able to self-organize into network topologies with the purpose of sharing resources such as content, CPU cycles, storage and bandwidth, capable of adapting to failures and accommodating transient populations of nodes while maintaining acceptable connectivity and performance, without requiring the intermediation or support of a global centralized server or authority. Dans cette définition ne sont considérés que les systèmes P2P s auto-organisant en un réseau sans le support d une autorité centrale, ce qui exclut une fois encore plusieurs systèmes P2P existant comme Napster [55] ou Boinc [14]. En revanche, elle met en évidence l objectif principal des systèmes P2P, à savoir la mutualisation des ressources des pairs participants au système [32]. Afin de pouvoir considérer l ensemble des systèmes P2P existant, il est nécessaire d avoir une définition qui ne considère que cet objectif, sans faire de suppositions sur comment le système y parvient. Ainsi, nous proposons la définition suivante : Définition : un système P2P est un système distribué où les participants mutualisent tout ou partie de leurs ressources afin de faire fonctionner les services proposés par le système. L avantage de cette définition est qu elle est suffisamment large pour englober n importe quel type de système P2P existant. En effet, en se focalisant sur l objectif de mutualisation des ressources des systèmes P2P, tout nouveau système remplissant cet objectif sera considéré comme un système P2P, même si la méthode pour y parvenir est nouvelle. 1.2 Développement des systèmes P2P Les systèmes P2P ont été développés au début des années 2000 [68] pour répondre à des besoins émergents résultant de la démocratisation des accès Internet à haut débit. En effet, le modèle Client/Serveur, dominant à l époque, n était pas prévu pour supporter ces nouveaux besoins comme la capacité de support du passage à l échelle ou la demande croissante de qualité de service [150]. Développé en parallèle dans les milieux universitaires et les communautés d utilisateurs sur Internet, de nombreux systèmes sont aujourd hui basés sur ce modèle d architecture, même au sein d entreprises privées. 9

26 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Répondre à des besoins émergents La démocratisation de l accès Internet haut débit au début des années 2000 a mis en évidence les limites du modèle Client/Serveur. En effet, l accroissement du nombre d utilisateurs ainsi que la demande croissante de services hautement disponible ne peuvent que difficilement être soutenus par une architecture Client/Serveur classique [150]. Ainsi, trois besoins majeurs ont conduit au développement des systèmes P2P : le passage à l échelle, la tolérance aux pannes et la décentralisation Passage à l échelle Le support du passage à l échelle correspond à la capacité d un système à soutenir l augmentation de son nombre d utilisateurs [150]. De par leur caractère centralisé, les systèmes basés sur modèle Clients/Serveur ne supportent pas le passage à l échelle. En effet, le serveur ayant des ressources limitées, il est dimensionné pour supporter un nombre maximum défini d utilisateurs. Or, avec l augmentation du nombre de personnes connectées et donc d utilisateurs potentiels, le besoin de support du passage à l échelle est devenu essentiel pour les systèmes informatiques depuis ces douze dernières années. Le modèle P2P permet de supporter le passage à l échelle, car ce type de système repose sur les ressources mutualisées d un nombre potentiellement illimité de machines. Cette propriété a été exploitée par des communautés sur Internet pour créer des systèmes reposant sur les ressources fournies par les utilisateurs du système eux-mêmes, permettant ainsi de créer des systèmes sans avoir recours à aucune infrastructure dédiée Tolérance aux pannes La tolérance aux pannes correspond à la capacité du système à assumer son service même si un ou plusieurs de ses composants deviennent indisponibles [11]. Le serveur d un système reposant sur un modèle Client/Serveur représente un point unique de rupture pour ce système. En effet, le serveur centralisant l ensemble des ressources du système, l indisponibilité de ce dernier entraine l indisponibilité de l ensemble des services du système. De base, le modèle Client/Serveur n assure donc aucune tolérance aux pannes. Si des solutions, comme l emploi de serveurs de secours, permettent d améliorer la tolérance aux pannes de ces systèmes, elles restent particulièrement onéreuses pour le gain qu elles apportent. À l inverse, le modèle P2P étant basé sur la mutualisation des ressources de plusieurs machines, l indisponibilité d une ou plusieurs machines n entraine qu une perte partielle de ressources pour le système. Ainsi, tant que la quantité de ressources reste suffisante, le système continue à fournir ses services aux utilisateurs. De plus, si ce sont les machines des utilisateurs qui fournissent les ressources au système, la diminution des ressources 10

27 1.2. Développement des systèmes P2P disponibles correspondent à une diminution du nombre d utilisateurs et donc de requêtes que le système aura à traiter Décentralisation La décentralisation consiste à répartir à la fois les données et les traitements sur plusieurs machines [150]. Avec l augmentation constante des quantités de données traitées par les systèmes distribués, il devient de moins en moins envisageable de centraliser l intégralité de celles-ci. Il est donc nécessaire de décentraliser, au moins en partie, les traitements et les données afin de limiter la quantité d informations devant être transmises entre les machines composant ce type de systèmes. Or cette décentralisation est contraire au principe de base du modèle Client/Serveur qui repose justement sur la centralisation à la fois des données et des traitements au niveau du serveur. À l inverse, le modèle P2P est par principe décentralisé. En effet, comme ce modèle repose sur la mutualisation des ressources des machines qui composent le système pour le faire fonctionner, les traitements et les données sont donc naturellement décentralisés Les premiers systèmes P2P L une des particularités des systèmes P2P est qu ils ont été développés parallèlement par les communautés sur Internet et par la communauté scientifique. Les premiers ont développé des applications complètes reposant sur des approches très pragmatiques, sans aucune validation scientifique, alors que les seconds ont proposé des systèmes aux performances validées scientifiquement, mais très rarement suivies d applications concrètes pour les utilisateurs finaux Les premières applications Les premiers systèmes P2P développés par les communautés sur Internet ont abouti à des systèmes de partage de fichiers entre les utilisateurs comme Napster [68], Gnutella [55], Kaaza [104], Edonkey [75] ou encore BitTorrent [79]. Ces systèmes sont caractérisés par une très grande diversité des approches utilisées. Ainsi, une grande partie des catégories de systèmes P2P que l on retrouve dans les classifications, comme celle d Eberspächer [55], décrivent des systèmes développés par les communautés sur Internet. C est par exemple le cas des systèmes P2P centralisés, purs et hybrides qui correspondent tous à des systèmes qui ont été développés par des communautés sur Internet [55]. La communauté scientifique n ayant pas pris part au développement de ces systèmes, les principales études sur ces systèmes reposent sur des mesures [104, 144, 79] et des analyses des protocoles [55, 75]. Ainsi, peu de technologies développées dans ces systèmes ont été réutilisées par la communauté scientifique. 11

28 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Les systèmes théoriques Simultanément au développement des premiers systèmes P2P par les communautés sur Internet, la communauté scientifique proposa ses propres systèmes comme CAN [131], Chord [151], Tapestry [177], Pastry [135], Kademlia[117], Symphony [113] ou Viceroy [112]. Tous ses systèmes reposent sur le principe d une table de hachage distribué (distributed hash table ou DHT). En pratique, ils permettent de router les messages en O(log(n)) retransmissions entre n importe quel couple de pairs, avec n le nombre de pairs présents dans le système. Ainsi, en associant les identifiants des informations des ressources stockées sur le système aux identifiants des pairs, ces systèmes permettent d effectuer des recherches par identifiants nécessitant en moyenne seulement O(log(n)) retransmissions. Si les performances de ces systèmes ont été intensivement étudiées par la communauté scientifique, le déploiement de systèmes réels basés sur ses approches a été très tardif. Ainsi, les premiers systèmes grand public reposant sur des DHT sont sortis en 2004 avec le réseau KAD [148] et CoralCDN [60] Domaines d applications des systèmes P2P Après la phase de développement des premiers systèmes entre 2000 et 2004, de nombreux systèmes P2P ont été proposés dans des domaines applicatifs variés. Ainsi, au-delà de l application historique de partage de fichiers, on retrouve des systèmes P2P dans des domaines tels que les middleware, la recherche documentaire, le stockage sécurisé, les outils de travail collaboratif, les calculs distribués ou encore la diffusion de données Middleware Créer un système P2P offrant des services évolués nécessite de gérer la complexité induite par la nature distribuée de ce type de système [46]. Afin de réduire cette complexité tout en profitant des avantages des systèmes P2P en terme de passage à l échelle, tolérance aux fautes et résilience, des systèmes à base de middleware P2P ont été développés. Le premier système P2P développé dans le but de fournir une solution middleware est JXTA [4, 6]. Ce système offre une série de services liés aux communications d applications. Il offre ainsi des services tels que la gestion de groupe de machines, le contrôle d accès ou encore un système de supervisions. Plus récemment, d autres middlewares basés sur des architectures P2P ont été développés afin de fournir des services de plus haut niveau que JXTA notamment des services de sécurité, de qualité de service ou encore de temps réel. Pour créer ces nouveaux systèmes P2P, des architectures telles que JXTA ont été associées à des cadriciels comme OSGi [61] ou CORBA [115]. 12

29 Système de recherche documentaire 1.2. Développement des systèmes P2P La recherche documentaire est un cas très particulier d applications ayant recours aux systèmes P2P. En effet, contrairement aux domaines précédents, les systèmes de recherche documentaire, reposant sur des bases de données relationnelles, sont difficilement décentralisables [91, 165]. La recherche sur ce type de système est très dynamique. L objectif de ces recherches est de pouvoir profiter des avantages des systèmes P2P comme la capacité de passage à l échelle et de tolérance aux pannes. De même, se passer de serveurs puissants pour le stockage et la recherche de données à très large échelle permettrait de réduire fortement le coût de tels systèmes. De nombreux systèmes P2P de recherche documentaire ont déjà été développés [97, 124, 54, 153, 31]. Certains d entre eux arrivent à reproduire des mécanismes de recherches complexes comme des recherches dans les espaces métriques [54, 153, 31] ou encore des recherches par mots-clefs [165, 97]. La principale limite de ces systèmes est leurs performances qui restent encore en retrait par rapport à des systèmes centralisées Système de stockage sécurisé La nature décentralisée des systèmes P2P qui leur permet de limiter les risques de pannes corrélées est particulièrement intéressante pour les systèmes de stockage sécurisés de données [95]. En effet, si des techniques d encodage de données comme les codes à effacements permettent de tolérer la corruption d une partie d un document sans compromettre sa lisibilité [12], elles ne peuvent suffire seule à garantir la tolérance aux pannes matérielles. Les système P2P de stockage sécurisé permettent d exploiter aux mieux ce type d encodage en fragmentant un document et distribuant ces fragments sur un grand nombre de pairs. Ainsi, même si un grand nombre de pairs subissent des pannes matérielles entrainant la perte des données qu ils hébergent, il est toujours possible de reformer les documents stockés par le système en collectant les fragments de documents encore disponible [38, 26]. De plus, pour renforcer la sécurité de ces systèmes, ils exploitent la nature décentralisée du modèle P2P pour implémenter des mécanismes de tolérance aux pannes byzantines [36]. Ainsi, chaque action sur les données est vérifiée par un ensemble de pairs afin d interdire les actes malveillants de la part d un pair présent dans le système [26] Système de travail collaboratif Le P2P est souvent utilisé comme infrastructure logicielle pour soutenir des applications de communication et de collaboration. Le P2P se prête tout particulièrement aux communications directes et temps réels comme les messageries instantanées, les chatrooms ou encore la VoIP [32]. Des systèmes très répandus tels qu IRC [85], Jabber [140] ou encore Skype [22] peuvent être considérés comme des systèmes P2P. 13

30 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Par principe, la communication directe entre plusieurs utilisateurs ne nécessite pas d avoir recours à un tiers. Ces systèmes peuvent donc assez naturellement être décentralisés, car aucun point central n est fondamentalement nécessaire à leur fonctionnement. Cela fait du P2P une solution particulièrement adaptée pour ce genre de système. Ce principe est repris par certains systèmes P2P, appelés Darknet [134], car cette absence de serveur central rend les communications entre les utilisateurs difficilement détectable par un tiers extérieur. Ainsi, de nombreux systèmes de travail collaboratif reposent sur ce type de système pour garantir la confidentialité de leurs échanges Système de calculs distribués Le principe de ces systèmes est de mutualiser les ressources de calculs inexploitées des machines qui y participent. Les deux projets les plus connus dans le domaine SETI@Home [15] et Folding@Home 1. Dans ces systèmes, les données à traiter sont distribuées entre les pairs pour qu ils effectuent les calculs quand ils passent en veille. Ainsi, ces systèmes utilisent les ressources du pair, quand celles-ci ne sont pas exploitées par l utilisateur, pour effectuer des calculs. En 2009, la puissance estimée du système Folding@Home passait la barre des cinq PétaFLOP. Cette approche a été généralisée sous une architecture commune appelée BOINC [14]. Cela a permis le développement de nombreux autres entre 2004 et aujourd hui Système de diffusion de données Le modèle P2P est une alternative intéressante pour la diffusion de données à un grand nombre d utilisateurs. En effet, les systèmes P2P permettent de pallier aux limites des solutions classiques comme le multicast IP sans pour autant nécessiter une infrastructure coûteuse comme c est le cas pour les réseaux d acheminement de contenu (Content Delivery Network) [159]. Dans ses systèmes, chaque pair retransmet les données qu il reçoit à d autres pairs afin que tous les pairs du système les reçoivent. Ce type d approche permet donc de diffuser des informations à un très grand nombre d utilisateurs sans nécessité d infrastructure. Ainsi, de nombreux systèmes de streaming audio/vidéo utilisent ce type de système P2P, comme Joost [72], CoolStreaming [102] ou Tribler [174] Développement des systèmes P2P dans l industrie En dehors de sociétés de l industrie du logiciel et du Web en général, l adoption de solutions basée sur des technologies P2P n est apparue que très tardivement. En effet, il Folding@Home : 2. BOINC stats, Project status information :

31 1.2. Développement des systèmes P2P faudra attendre le développement du Cloud Computing, qui repose massivement sur des systèmes P2P, pour que l emploi du modèle P2P se démocratise dans l industrie Google La spécificité de l architecture de Google est d être massivement distribuée. Elle exploite donc de nombreux principes que l on retrouve dans les systèmes P2P classique. Ainsi, son système de fichier GFS [64] repose sur une architecture très similaire à Napster [55] alors que son moteur de recherche [49] est semblable à celui de Gnutella [55]. L architecture Google se différencie d un système P2P classique [55] par la nature des pairs et le réseau qui les relie. En effet, l ensemble des machines composant leurs systèmes sont des serveurs qu ils administrent eux-mêmes, ce qui limite les problématiques d attrition que l on retrouve dans la plupart des systèmes P2P. De même, ces pairs sont reliés par un réseau dédié pouvant offrir des services comme le broadcast des messages que ne le pourrait un overlay sur le réseau Internet. Néanmoins, certaines technologies développées par Google sont directement réutilisables dans les systèmes P2P plus classique par exemple le cadriciel MapReduce [50] Microsoft Plusieurs systèmes P2P ont été développés dans les laboratoires de recherche de Microsoft. Farsite [10] et Pastry [135] sont surement les plus connus d entre eux. En revanche, peut de produit reposant sur ces technologies ont été exploité cette société. Ainsi, les deux exemples les plus notables de produit Microsoft exploitant des technologies P2P sont Groove [53] qui fut ensuite intégré dans SharePoint 3 et Windows Live Mesh 4. Le premier est un système de travail collaboratif et de partage documentaire principalement axé sur des fonctionnalités de sécurité. Windows Live Mesh, de son côté est un outil de synchronisation de dossiers qui peut fonctionner soit en mode Cloud soit directement en mode P2P entre deux machines ou plus Amazon La société Amazon a développé son propre système P2P, appelé Dynamo [51], pour gérer une partie de son stockage de données. Ce système est une tables de hachage distribuées qui permet à Amazon de garantir une très haute disponibilité pour ses services tout en profitant des propriétés de passage à l échelle de son système pour mieux gérer ses investissements de matériel. 3. SharePoint Workspace 2010 : dix-bonnes-raisons-dessayer-sharepoint-workspace-2010-ha aspx 4. Windows Live Mesh : essentials-other-programs?t1=t4 15

32 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Émergence du Cloud Computing Depuis quelques années, le Cloud Computing se développe et est peu à peu adopté par les entreprises. De par le besoin de passage à l échelle et leur nature distribuée, le modèle P2P s impose comme une solution avantageuse pour interconnecter les serveurs qui composent le nuage 5 [168, 18, 67]. Ainsi, les services de Cloud Computing des sociétés précédemment cité comme Google [64, 49] et Amazone [51] reposent sur des systèmes P2P. De même, des systèmes comme Hadoop 6. Les systèmes P2P commencent donc à être utilisés dans les entreprises par le biais du Cloud Computing. 1.3 Bilan de 12 années de développement des systèmes P2P Depuis les premières propositions de systèmes P2P à la fin des années 1999, le nombre de propositions dans le domaine n a fait que croitre et commence seulement à se stabiliser. Ainsi, de très nombreux systèmes ont été proposés afin de répondre aux différents compromis de performances que l on pouvait attendre de ce type de système ainsi qu aux différents contextes applicatifs dans lesquels ils peuvent être utilisés Multiplication des systèmes Durant les douze dernières années, de très nombreux systèmes P2P ont été proposés. La bibliothèque numérique des ACM 7 recense environ 5500 articles dans le domaine du P2P, soit une moyenne de 460 articles par an. Or la majorité des concepts originaux ont été développés entre fin 1999 et 2005 [55]. Ainsi, les nouveaux systèmes proposés ces dernières années correspondent principalement à de nouvelles versions de systèmes existants pour chaque compromis sur les performances et chaque contexte d applicatif Pour chaque compromis sur les performances De très nombreux systèmes P2P qui ont été proposés sont des optimisations des premiers systèmes P2P présentés au début des années En effet, à partir d un même concept, de nouveaux mécanismes ont été proposés afin de permettre la création de systèmes offrant différents compromis de performances. Si certaines de ces propositions ont été présentées indépendamment d un système donné [86, 114], une très grande majorité de 5. Clouds and peer-to-peer : clouds-and-peer-to-peer.html 6. Apache Hadoop : 7. ACM Digital Library : 16

33 1.3. Bilan de 12 années de développement des systèmes P2P ces optimisations ont donné lieu à des systèmes complets [41, 100, 93]. Il est donc difficile de déterminer l applicabilité de ces propositions à d autres systèmes que ceux présentés dans ces travaux. Par exemple, le système Chord [151] est la base de nombreux systèmes P2P proposés pendant ces douze dernières années. Ainsi, plusieurs systèmes se revendiquent clairement comme des variations du système Chord comme EpiChord [100] ou Re-Chord [93]. D autres systèmes reprennent aussi moins explicitement les bases posées par Chord, comme Symphony [113], Viceroy [112] ou même Kademlia [117]. Ainsi Symphony est une version modifiée de Chord qui reprend le mécanisme de sélection des liens entre les pairs définie par Kleinberg [92]. Viceroy ajoute une seconde structure à celle de Chord afin de mieux répartir les liens à maintenir entre les pairs. Enfin, Kademlia reprend plusieurs améliorations déjà existantes comme le routage bidirectionnel de Symphony [113] et le mécanisme de maintenance de Tangle [41], qu il applique à Chord grâce à une nouvelle métrique en XOR. Cette diversité de systèmes présentant des compromis de performances basées sur un même concept, rendent difficilement réutilisable les optimisations qu ils proposent. En effet, il est parfois difficile de distinguer ce qui relève d une optimisation spécifique à un système donné, d une optimisation pouvant être utilisée dans une plus large variété de systèmes. Ainsi, il est très difficile de voir les similitudes entre Chord et Kademlia sans étudier profondément les protocoles des deux systèmes Pour chaque contexte applicatif De nombreux systèmes P2P ont été proposés pour différents domaines applicatifs. Comme pour les optimisations, ces systèmes correspondent principalement à des variations basées sur les premiers systèmes développés que de nouveaux concepts. Ainsi, pour reprendre l exemple de Chord, ce système a été utilisé comme base pour de nombreux domaines applicatifs. Ainsi, des systèmes basés sur Chord ont été proposés dans des domaines aussi variés que les Smart Grids [139], le multicast applicatif [123], la supervision de systèmes distribués [27], la distribution d infrastructure de sécurité [101], le calcul distribué [8] ou encore la recherche documentaire [125]. Comme pour les optimisations, la multiplication de systèmes basés sur les mêmes concepts rend difficilement réutilisables dans d autres systèmes les nouveaux mécanismes qui sont proposés. Ainsi, si pour certaines de ces propositions, les nouveautés proposées sont facilement portable à d autres systèmes, comme l index permettant les recherches dans un espace métrique de MChord [125], dans d autres cas, cette portabilité n est absolument pas évidente, comme le mécanisme d agrégation de Binzenhofer et al. [27]. 17

34 Chapitre 1. Le modèle P2P : une alternative au modèle Client/Serveur Limites des classifications proposées Afin d avoir une vue d ensemble et analyser les systèmes basés sur le modèle P2P, il est nécessaire de classifier ces systèmes en fonction de caractéristiques communes. De nombreux états de l art et donc de classifications des systèmes P2P ont été proposés au cours des douze dernières années. Parmi les critères utilisés pour classifier l ensemble des systèmes, on trouve la structuration de l overlay [55, 16, 45, 108], le degré de décentralisation [55, 16, 45, 80] et le type d indexation des données [80, 157]. Le nombre de critères utilisés dans chacune de ces différentes classifications est relativement faible et ne permet pas de classer certains systèmes comme Freenet [40], qui utilise une table de hachage distribué sur un overlay non-structuré. De même, ce niveau de granularité ne permet pas de discriminer les différentes optimisations et approches développées à partir des mêmes systèmes de bases. Chacune de ses classifications développe sa propre terminologie. Ainsi, le terme hybride peut représenter un système partiellement centralisé [55], un système possédant un serveur central [16] ou un système exploitant plusieurs approches simultanément pour la création de son overlay [45, 108, 80]. Comme le précise Camarillo dans [32], cette diversité dans le sens donné aux termes utilisés pour classifier les systèmes P2P limite la capacité de création d une taxonomie commune pour l ensemble du domaine. Les différentes classifications existantes ne permettent donc pas d avoir une vue d ensemble des travaux proposés. Or cette vue d ensemble est nécessaire pour rationaliser l importante production scientifique sur les systèmes P2P des douze dernières années. En effet, il est aujourd hui difficile de distinguer l ensemble des possibilités offertes par les travaux qui ont déjà été publiés et donc de déterminer si une proposition n a pas déjà été formulée en utilisant une terminologie différente. 1.4 Conclusion Les systèmes P2P ont connu une croissance extrêmement rapide au cours des douze dernières années. Développé parallèlement par les communautés sur Internet et dans le milieu académique un très grand nombre de systèmes différents ont rapidement été proposés, offrant ainsi un grand nombre de possibilités. Aujourd hui, le modèle P2P représente une alternative concrète au modèle Client/Serveur dans de nombreux domaines d applications comme les middlewares, la recherche documentaire, le stockage sécurisé, le travail collaboratif, le calcul distribué ou encore la diffusion de données au point d être peu à peu adopté dans des contextes industriels. Pourtant, une grande partie des systèmes proposés ne sont en réalité que des adaptations et des optimisations des premiers systèmes développés au début des années Ainsi, très peu de systèmes originaux ont été créés au cours des douze dernières années. Cela peut s expliquer par le manque de rationalisation du domaine. En effet, s il existe de nombreux états de l art portant sur les systèmes P2P, ces dernières reposent sur des clas- 18

35 1.4. Conclusion sifications basées sur un faible nombre de critères. Ainsi, si ces classifications permettent de décrire l existant, elles ne sont pas assez précises pour permettre de l analyser [32]. Or, sans une analyse précise du domaine, il est difficile de pouvoir proposer de nouveaux systèmes originaux. De plus, le manque de précision dans ces classifications masque une grande partie des optimisations qui ont été proposées au cours de ces dernières années. Une nouvelle classification du domaine est donc nécessaire afin d avoir une vue d ensemble du travail accompli et donc permettre la réutilisation des mécanisme existant pour la composition de nouveaux systèmes P2P. 19

36

37 CHAPITRE 2 ANALYSE FONCTIONNELLE DES SYSTÈMES P2P EXISTANTS Dans ce chapitre, nous proposons une analyse des systèmes P2P existant afin de proposer une vue d ensemble du domaine. Bien qu il existe déjà plusieurs états de l art sur ce domaine, ils ne proposent qu une description des systèmes existant en les classant en fonction de leurs propriétés macroscopiques. Contrairement à ces approches, nous proposons une analyse fonctionnelle des systèmes P2P dont le but n est pas de décrire le domaine, mais de mettre en avant les différentes fonctionnalités qui ont été développées au cours de ces douze dernières années. Notre objectif est de proposer une vue d ensemble des approches qui ont été développées afin de faciliter leur réutilisation pour la composition et de systèmes P2P adaptés à des contextes applicatifs donnés. Ainsi, après avoir décrit notre principe d analyse, nous présenterons les différentes approches qui ont été proposées dans l existant en mettant en avant leurs propriétés et leurs spécificités pour faciliter leur réutilisation pour la composition de systèmes P2P ou identifier des manques et donc guider le développement de nouvelles approches facilement réutilisabe. 2.1 Principes d analyses : une division des systèmes en trois couches fonctionnelles Le nombre de systèmes P2P proposés au cours de ces douze dernières années, que ce soit dans les milieux académiques ou par les communautés sur Internet, est particulièrement grand. Afin de prendre en compte l ensemble de l existant, nous avons proposé une définition qui peut aussi bien recouvrir les grappes de calculs que les systèmes totalement décentralisés et sans infrastructure comme Chord [151] ou Gnutella 0.4 [55]. Pour analyser un tel ensemble, il est nécessaire de le décomposer soit en plusieurs 21

38 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants grands ensembles, comme cela est fait dans [16, 98] ou alors décomposer les systèmes euxmêmes en des blocs fonctionnels indépendants pour réduire la porté de l analyse. Notre objectif étant de dégager des grandes classes de systèmes P2P partageant des propriétés communes, il est nécessaire de considérer l ensemble des systèmes existants au moment de l analyse. Ainsi, seule la décomposition des systèmes en bloc fonctionnel permet d atteindre cet objectif. Afin d analyser l ensemble des systèmes P2P, nous nous inspirons du modèle OSI [1] en décomposant ces systèmes en trois couches. Chacune de ces couches correspond à un ensemble de fonctionnalités ou primitives que l on retrouve dans la plupart des systèmes existants [32]. L avantage d une approche basée sur un empilement de couches est qu elle permet de capter la grande diversité des systèmes P2P existants. En effet, comme dans le modèle OSI, une couche correspond à un ensemble de fonctionnalités qui peuvent êtres appelées par les couches qui lui sont directement adjacentes. Ainsi, si les fonctionnalités apportées par une couche ne sont pas nécessaires à un système, la couche n est simplement pas implémentée. De même, un système peut implémenter plusieurs fonctionnalités au niveau d une même couche afin de pouvoir gérer des besoins très différents [105]. Les trois couches que nous avons retenues (Fig. 2.1) pour cette analyse correspondent à des ensembles de fonctionnalités que nous retrouvons dans les systèmes P2P existant, à savoir l adaptation du réseau hôte, l indexation des ressources et les applications. Figure 2.1 Segmentation des systèmes P2P en trois couches fonctionnelles Couche d adaptation du réseau hôte Cette couche fournit aux pairs l ensemble des fonctionnalités nécessaires à leurs communications. En pratique, on fait l hypothèse que le réseau hôte permet à n importe quel pair de communiquer avec un autre pair du système du moment que celui-ci possède les informations nécessaires, par exemple son adresse IP. 22

39 2.1. Principes d analyses : une division des systèmes en trois couches fonctionnelles Les fonctionnalités fournies par cette couche sont dépendantes des besoins en communications des couches supérieures. Ces fonctionnalités peuvent aller de la simple diffusion des messages à des mécanismes d adressage et de routage des messages. En plus de fournir les primitives nécessaires aux communications entre les pairs, c est la couche d adaptation du réseau hôte qui va déterminer plusieurs propriétés fondamentales du système, comme la capacité de passage à l échelle, la tolérance aux pannes ou encore le temps de latence des transmissions Couche d indexation des ressources L objectif de cette couche est de permettre de retrouver les ressources mutualisées par les pairs dans le système. En effet, chaque pair mutualise une partie de ses ressources pour faire fonctionner le système, ces ressources pouvant être de l espace disque, des capacités de traitement ou encore des documents. Ces ressources étant distribuées sur l ensemble des pairs participant au système, il est nécessaire d avoir des fonctionnalités permettant de retrouver les ressources en fonction des besoins des pairs. Les fonctions de la couche d indexation dépendent principalement des ressources et de leurs répartitions entre les pairs. En effet, si il existe un grand nombre de ressources différentes dans le système, il sera plus difficile de retrouver une ressource particulière sur celui-ci. De même, si des ressources similaires sont regroupées sur des pairs particuliers, il est plus facile de les retrouver que si chaque pair est susceptible de posséder n importe quelle ressource. Les fonctionnalités pouvant être développées au niveau de la couche d indexation dépendent de celles présentes au niveau de la couche d adaptation du réseau hôte. En effet, les primitives de communications disponibles entre les pairs impactent les capacités de recherche de ressources dans un environnement distribué Couche application Cette couche a pour but de masquer la complexité inhérente à la nature distribuée du système. Elle gère le rapprochement des données et les capacités de traitements distribuées sur l ensemble du système afin de réaliser les services que celui-ci propose aux utilisateurs. La couche application repose sur l interaction de deux types de fonctionnalités que sont le partage de données et le traitement distribué. Le partage de données permet de déplacer les données vers les pairs désignés par la fonctionnalité de traitement distribué comme possédant les capacités adéquats. Les fonctionnalités de la couche application dépendent des services qui seront proposés par le système. En effet, de ces services dépendent les traitements qui devront être réalisés par le système. De même, ces fonctionnalités sont elles-mêmes impactées par les primitives développées dans les couches précédentes. 23

40 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants 2.2 Classification des différentes approches utilisées dans les systèmes P2P Nous allons donc étudier les systèmes P2P existants en fonction des trois couches que nous avons définies dans la section précédente. Ainsi, les systèmes existants seront classés selon trois différents critères, les mécanismes d adaptation du réseau hôte, d indexation des ressources et d application Couche d adaptation du réseau hôte Cette couche est consacrée aux fonctionnalités permettant aux pairs de communiquer entre eux en exploitant un réseau de communication préexistant. Techniquement, pour que deux pairs communiquent, il faut qu au moins l un d entre eux possède les informations nécessaires pour que le réseau hôte transmette les messages à l autre pair. Afin de simplifier l étude, nous considérerons que le réseau hôte est l Internet. En effet, bien que d autres réseaux hôtes puissent être utilisés, en pratique, seul le cas de l Internet est généralement considéré dans les systèmes P2P [57]. Nous ferons donc de même ici. On distingue deux approches permettant d atteindre cet objectif, à savoir l utilisation d un serveur d adressage et l utilisation d un overlay, cette dernière étant la plus majoritairement utilisée Serveur d adressage Le principe de cette approche est de centraliser les informations nécessaires aux communications entre les pairs au niveau d un serveur [55, 79]. Ce serveur contient toutes les informations permettant de contacter n importe quel pair sur le réseau hôte. Ainsi, quand un pair veut communiquer avec un autre pair du système, il contacte le serveur d adressage afin obtenir les informations qui lui manque pour envoyer un message à ce pair (Fig. 2.2). Une approche reposant sur un serveur d adressage se définit par la centralisation au niveau d un serveur d un index reliant chaque pair à un couple adresse IP et numéro de port. Chaque pair du système connaît l adresse IP et le numéro de port de celui-ci pour pouvoir l interroger à tout moment. En pratique, cet index peut contenir plus d informations que le simple triplet n Port], mais celle-ci correspondent aux informations minimums qui doivent être présentes. De même, l index doit être centralisé, mais le nombre de serveurs utilisés peut varier. En effet, un système distribué peut être utilisé comme serveur d adressage [75], tant que n importe quel pair du système peut y accéder. L utilisation d un serveur d adressage est un cas limite pour les systèmes P2P qui tendent à être décentralisés. Ils possèdent donc des propriétés plus proches d un système basé sur le modèle Client/Serveur que d un système P2P. En effet, de par la centralisation 24

41 2.2. Classification des différentes approches utilisées dans les systèmes P2P Figure 2.2 Utilisation d un serveur d adressage pour l adaptation du réseau hôte. Chaque pair est connecté au serveur afin de localiser les autres pairs du système et créer des connexions ad hoc les uns avec les autres des informations nécessaires à la communication entre les pairs au niveau d un serveur, les systèmes utilisant un serveur d adressage pour l adaptation au réseau hôte ne supportent pas le passage à l échelle [55]. Comme l ensemble des pairs du système doit interroger le serveur d adressage pour pouvoir communiquer entre eux, et que ce dernier possède des ressources limitées, le système ne peut pas supporter un accroissement du nombre de pairs au-delà d une certaine limite, sans changer le serveur lui-même. De plus, le serveur d adressage est un point unique de rupture pour l ensemble du système [55], dans le sens où les pairs ne peuvent plus se trouver les uns les autres si le serveur n est plus disponible. En contrepartie, un système P2P utilisant un serveur d adressage possède certains avantages. Premièrement, le nombre de messages échangés pour retrouver un pair dans le système est à la fois faible et borné [55]. En effet, un simple échange avec le serveur est nécessaire pour retrouver un pair, soit deux messages. C est particulièrement faible par rapport aux autres solutions existantes. De même, cette approche permet de trouver facilement des ensembles de pairs, le serveur pouvant gérer de façon centralisée des recherches complexes sur son index. Enfin, le serveur d adressage simplifie la gestion du système. En effet, en enlevant les informations relatives à un pair dans l index du serveur, on exclut ce pair du système en le rendant inaccessible pour les autres pairs. De même, la centralisation d informations sur l ensemble des pairs permet de recueillir des informations de gestions comme le nombre de pairs présent dans le système à un instant donné ou avec quels autres pairs un pair donné communique Les overlays Cette approche vise à proposer une solution décentralisée pour l adaptation du réseau hôte. Dans un overlay, chaque pair du système possède les informations nécessaires pour contacter un sous-ensemble de pairs de sorte à former un réseau virtuel [98]. Pour communiquer avec un pair particulier du système, un pair envoie son message à un ou plusieurs 25

42 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants pairs dont il possède les informations qui retransmettront le message à d autres pairs du système jusqu à ce que le message atteigne le pair ciblé (Fig. 2.3). Figure 2.3 Représentation d un overlay. Chaque pair maintient un nombre limité de connexions avec d autres pairs du système afin de transmettre les messages de pair en pair jusqu à atteindre sa destination. Un overlay se définit par la retransmission des messages de pair en pair afin de permettre à n importe quel couple de pairs du système de communiquer entre eux. Pour ce faire, chaque pair maintient l adresse IP et le numéro de port d autres pairs participant au système afin de pouvoir communiquer directement avec eux [55, 151]. On dit que deux pairs sont liés, ou connectés, quand l un des pairs connaît l adresse IP et le numéro de port de l autre pair. Si le pair destinataire d un message ne fait pas partie des pairs connus, le message est retransmis à un ou plusieurs pairs connus jusqu à ce qu il atteigne sa destination. Le nombre de liens maintenus par chaque pair du système peut varier de l ensemble des pairs présent [37] à un seul autre pair [55], en fonction des propriétés que l on souhaite obtenir. Ces liens n étant pas obligatoirement bidirectionnels, il faut qu un pair possède au moins un lien sortant et un lien entrant pour faire partie du système. De même, si l objectif est de permettre à n importe quel couple de pairs de communiquer, cet objectif n est pas forcément atteint à tout moment. Ainsi, même si il tend à l être, le graphe formé par un overlay peut ne pas être connexe [69]. Les overlays sont une solution souple permettant de satisfaire les besoins fonctionnels comme la retransmission des messages et les besoins non fonctionnels comme la tolérance aux pannes et le support du passage à l échelle nécessaire au système [46]. Dans son instanciation la plus simple, un overlay est composé de pairs égaux créant un nombre fixe de liens avec d autres pairs du système choisi aléatoirement [55]. Dans ce type d overlay, les pairs n ont aucune connaissance du système au-delà des autres pairs auxquels ils sont connectés. Il existe deux méthodes pour transmettre un message entre deux pairs non reliés l un à l autre, l inondation [55] ou la marche aléatoire [37]. Dans le cas de l inondation, le message est soit retransmis à l ensemble des pairs auxquels il est connecté. Cette approche permet de trouver le plus court chemin entre deux pairs et ainsi 26

43 2.2. Classification des différentes approches utilisées dans les systèmes P2P limiter le temps nécessaire pour que le message atteigne sa destination. En revanche, elle nécessite un grand nombre de retransmissions du message sur le système [55]. Dans le cas de la marche aléatoire, le message est retransmis à un seul pair choisi aléatoirement. Si cette approche permet de limiter le nombre de retransmissions du message sur le système, elle n offre aucune garantie sur la longueur de la chaîne créée pour que le message atteigne sa destination [37]. Le principal avantage des overlays est sa grande tolérance aux pannes. En effet, la panne simultanée d un grand nombre de pairs du système ne remet pas en cause le fonctionnement du système [11]. En revanche, ces pannes peuvent fragmenter le système en plusieurs overlays indépendants ce qui, dans certains cas, peut compromettre son fonctionnement global. En pratique, ce type d overlay est limité par le manque de connaissance des pairs sur le système, ainsi les mécanismes de retransmission des messages qui peuvent être utilisées ne permettent pas à ce type de système de supporter le passage à l échelle. En effet, dans le cas de l inondation, le nombre de retransmissions des messages sature rapidement les pairs quand ceux-ci deviennent trop nombreux [55]. De même, dans le cas de la marche aléatoire, plus le nombre de pairs participant au système est important, plus la taille de la chaîne formée pour atteindre le pair ciblé augmente, augmentant ainsi fortement le temps de réponse. Pour répondre à ces limites, deux variantes ont été proposées, la hiérarchisation de l overlay et sa structuration [45, 179]. Ces deux approches pouvant elle-même être combinées pour obtenir des overlay à la fois hiérarchiques et structurés [62] Hiérarchisation L une des approches visant à améliorer le support du passage à l échelle d une approche à base d overlay consiste à augmenter le nombre de connexions entrantes et sortantes de certains pairs du système. En effet, les pairs participants au système peuvent être hétérogènes dans le sens où certains peuvent posséder plus de capacité de traitement ou plus d espace mémoire que les autres. Ainsi, en augmentant le nombre de liens de ces pairs, le diamètre du graphe formé par l overlay diminue sans pour autant augmenter la charge des pairs les moins performants [37] (Fig. 2.4). On peut distinguer deux méthodes pour hiérarchiser un overlay que l on qualifiera de souple ou dure. Dans le cas d une hiérarchisation souple, tous les pairs du système ont le même rôle. Ils possèdent donc le même algorithme de routage des messages ou de sélection des pairs auxquels ils se connectent. Si cette approche réduit le diamètre du graphe formé par l overlay, elle ne permet pas directement d améliorer la méthode de transmission des messages. Pour atteindre cet objectif, on y ajoute un mécanisme permettant aux pairs liés entre eux de s échanger des informations sur le nombre de connexions qu ils entretiennent avec d autres pairs du système [37]. En effet, en biaisant un mécanisme de marche aléatoire pour que les messages soient dirigés prioritairement vers les pairs possédants un grand nombre de connexions, on augmente les chances que l un de ces pairs soit lié au pair ciblé par le message. 27

44 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants Figure 2.4 Organisation d un overlay hiérarchisé. Les pairs feuilles sont connectés à des super-pairs (représenté ici par des serveurs) qui sont eux-mêmes interconnectés les uns aux autres par un overlay. Ces deux niveau d overlay sont utilisés pour retrouver un pair particulier dans le système afin de créer une connexion directe avec lui pour s échanger des informations. Dans un overlay avec une hiérarchie dure, il existe plusieurs types de pairs possédant chacun des rôles différents. Cette approche permet d organiser les pairs en fonction de leurs capacités de traitement et de stockage. On distingue généralement deux types de pairs, les pairs-feuilles et les super-pairs [55]. Un pair feuille est un pair qui possède peu de capacités de traitement ou d espace de stockage, le nombre de liens qu il entretient avec d autres pairs du système est donc limité pour ne pas le surcharger. Ils sont donc connectés à un nombre défini de super-pairs. Ces super-pairs sont des pairs possédants d importantes ressources de traitement et de stockage. Ils entretiennent un nombre défini de connexions les uns avec les autres et sont aussi connectés à un nombre défini de pairsfeuilles. Comme pour la hiérarchisation souple, la hiérarchisation dure permet de réduire fortement le diamètre de l overlay. De plus, en différenciant formellement différents types de pairs, il est possible de différencier le mécanisme de diffusion des messages pour chacun d eux. Ainsi, dans le cas d une transmission par inondation, celle-ci peut être limitée au réseau formé par les super-pairs et uniquement retransmis aux pairs-feuilles ciblés [55]. La principale limite de la hiérarchisation est qu elle réduit la tolérance aux pannes du système. En effet, les pannes touchants les pairs possédant un grand nombre de liens impactent plus fortement le système que celles touchant les pairs les moins connectés. Cette particularité rend ce type de système vulnérable à une attaque visant les pairs les plus connectés du système [11]. En revanche, en considérant que la proportion de pairs possédants d importantes capacités de traitement et de stockage sur le système est constante, la hiérarchisation permet à un overlay de supporter le passage à l échelle [55]. 28

45 2.2. Classification des différentes approches utilisées dans les systèmes P2P Structuration L objectif de cette approche est d organiser le graphe créé par l overlay afin de fournir aux pairs suffisamment d informations pour router les messages. Pour ce faire, chaque pair possède des coordonnées dans un espace métrique commun à l ensemble des pairs du système, ces coordonnées servent d identifiant pour chaque pair du système. À partir de ces informations, chaque pair se connecte avec d autres pairs en fonction de la distance qui les sépare de sorte à créer des liens, que l on appelle liens courts, avec l ensemble de ses voisins sur l espace métrique [66, 92] (Fig. 2.5). Ce type de construction permet à chaque pair du système de retransmettre un message de proche en proche jusqu à sa destination. Figure 2.5 A) Représentation des liens courts entre les pairs dans un espace métrique utilisant une distance de Manhattan sur 2 dimensions. B) Représentation des liens longs d un pair sur cette espace métrique. La particularité des overlay structurés est qu ils peuvent trouver des chaînes courtes reliant n importe quel couple de pairs du système en se basant uniquement sur la distance qui sépare un pair du pair destinataire du message. La longueur de cette chaîne de retransmission d un message est dépendante du diamètre du graphe formé par l overlay. En effet, si il est nécessaire qu un pair soit connecté à l ensemble de ses voisins sur l espace métrique pour garantir l acheminement d un message à destination [113], il est possible d ajouter d autres connexions pour améliorer les performances de routage. En effet, l ajout de liens, que l on appelle des liens longs, avec des pairs éloignés sur l espace métrique permet de réduire le diamètre de l espace métrique [43] et ainsi réduire la taille de la chaîne de retransmission. Si ajouter des liens longs choisis aléatoirement permet de réduire le diamètre du graphe, cela ne permet pas à un algorithme distribué de retrouver les chaînes les plus courtes reliant deux pairs du système [92]. En effet, dans cette situation, un pair n a aucun moyen de connaître la répartition des liens longs des autres pairs auquel il est connecté et donc ne peut pas avoir connaissance de chemins potentiellement intéressants. Dans ces travaux sur les small-world, Kleinberg a prouvé que la répartition des liens longs en fonction de la distance entre deux nœuds d un graphe influait sur la longueur des chaînes que pouvait trouver un algorithme distribué [92]. De plus, il a prouvé que la distribution optimale pour limiter la longueur de cette chaîne devait être proportionnelle à l inverse de 29

46 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants la distance élevée à une puissance égale au nombre de dimensions de l espace métrique. Cette répartition permet, pour un nombre de liens longs par pair fixe, d avoir une longueur de chaîne de retransmission qui croit de façon polylogarithmique en fonction du nombre de pairs dans le système [92]. C est ce type de distribution qui est utilisée par des systèmes P2P reposant sur un overlay structuré [151, 177, 131, 113, 117, 135] (Fig. 2.6). Figure 2.6 Répartition des liens du pair P 0 dans le système Chord. L avantage d une approche structuré est qu elle permet de transmettre les messages entre un couple quelconque de pairs du système par une chaîne de retransmission courte sans avoir recours à un mécanisme d inondation. Cela permet au système de supporter le passage à l échelle du nombre de pairs participant au système en ayant une croissance polylogarithmique du nombre de retransmissions nécessaire pour qu un message atteigne sa destination [92]. En revanche, pour obtenir ses performances, il faut que l organisation des liens entre les pairs reste conforme au modèle. Ainsi, il faut que chaque pair du système maintienne ses liens courts avec l ensemble de ses voisins dans l espace métrique pour garantir que le message atteigne sa destination [113]. De même, il faut que la répartition des liens longs entre les pairs soit proportionnelle à celle définie par Kleinberg pour que la taille de la chaîne de retransmission ait une croissance polylogarithmique en fonction du nombre de pairs dans le système [92]. En conséquence, il faut que les liens entre les pairs soient maintenus pour que les performances de routage restent stables, ce qui nécessite des échanges de messages réguliers entre les pairs [66]. Ainsi, ces systèmes supportent mal le phénomène d arrivées et de départs réguliers des pairs, que l on appelle attrition ou churn. 30

47 2.2. Classification des différentes approches utilisées dans les systèmes P2P Couche d indexation Pour qu un système P2P fonctionne, chaque pair du système met à sa disposition une partie de ses ressources. Ses ressources peuvent être des documents, de l espace de stockage, de la capacité de traitement... L enjeu de la couche indexation est de permettre au système P2P de retrouver ses ressources qui sont distribuées sur l ensemble des pairs qui le compose. Pour ce faire, toutes des ressources du système sont indexées afin de permettre à un algorithme de recherche de les retrouver [80]. On peut distinguer quatre types d index [157] qui ont été utilisés dans les systèmes P2P : un index global, des index locaux, des index partagés et enfin un index distribué. Chacun de ces types d index ayant des propriétés différentes peut nécessiter la présence de certaines primitives au niveau de la couche d adaptation du réseau hôte Index global Dans cette approche, toutes les ressources du système sont indexées dans un index unique hébergé dans sa totalité par un ou plusieurs pairs. Un index global relie chaque ressource du système aux pairs qui la possède et peut être enrichie d informations supplémentaires permettant d étendre les capacités de recherche du système [42, 55]. L avantage d un index global est de permettre d effectuer localement des recherches sur l ensemble des ressources du système. Cela permet d utiliser des algorithmes complexes d organisation et de recherche sur les données indexés [64]. En contrepartie, ce type d index souffre de plusieurs limites. En effet, un index global comprenant des informations sur l ensemble des ressources du système, chaque ajout, suppression ou modification d une de ces ressources doit être répercutée au niveau de celui-ci. Cette approche supporte donc mal l attrition des pairs dans le système. De plus, la taille de l index croit avec l augmentation du nombre de ressources et de pairs présents dans le système. Cette approche ne permet donc pas au système de supporter le passage à l échelle que ce soit en nombre de pairs ou en quantités de ressources mises à disposition [42, 55]. Il existe deux façons de mettre en œuvre un index global, une approche centralisée, et une approche répliquée Centralisé Dans ce type d approche, l index global est centralisé au niveau d un ou plusieurs serveurs qui seront interrogés par les pairs quand ces derniers chercheront des ressources dans le système [171]. Ainsi, à chaque fois qu une ressource d un pair est ajoutée, supprimée ou modifiée, ce pair doit contacter le serveur pour que l index soit mis à jour. Cette solution est particulièrement intéressante quand elle est associée à une adaptation du réseau hôte basée sur un serveur d adressage [55, 75]. En effet, cela permet d utiliser le même serveur pour gérer l indexation et l adaptation du réseau hôte. De même, ces deux approches étant toutes deux limitées par la présence de cet élément central, elles 31

48 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants partagent les mêmes désavantages. Ainsi, un index global centralisé sur un serveur est un point unique de rupture pour le système. En effet, une panne du serveur empêchant les pairs de retrouver les ressources distribuées [55] Répliqué Dans ce type d approche, l index global est répliqué sur l ensemble des pairs du système [42]. Chaque pair peut alors, en local, retrouver n importe quelles ressources présentes dans le système. De même, les informations sur l ajout, la suppression ou la modification d une ressource doivent être diffusées à l ensemble des pairs. Contrairement à une approche centralisée, il n y a pas ici de point unique de rupture, l index global étant présent au niveau de chaque pair. En revanche, elle nécessite que chaque pair maintienne des informations sur l ensemble des ressources du système, ce qui implique que le nombre de ressources doit rester faible [42]. De même, la diffusion des informations sur les ressources à l ensemble des pairs implique l échange d un très grand nombre de messages, surtout si les ajouts, suppressions et modifications sont fréquents. Ainsi, ce type d approche n est applicable que si le système conserve un nombre de pairs restreint. En pratique, cela représente des systèmes contenant moins de dix mille pairs [42] Index locaux Dans cette approche, chaque pair maintient un index relatif uniquement aux ressources qu il met lui-même en partage [80] [55]. Ainsi, les pairs ne possèdent aucune information sur les ressources mises en partage par les autres pairs du système. Pour effectuer une recherche sur des index locaux, il est donc nécessaire de contacter l ensemble des pairs du système afin que toutes les ressources présentes soient prises en compte [178]. Le principal avantage d utiliser des index locaux est sa forte tolérance aux pannes. En effet, l index ne contenant que des informations sur les ressources locales, il n est pas modifié quand une ressource d un autre pair est ajoutée, supprimée ou modifiée. De plus, ils offrent de très bonnes performances en terme de confidentialité sur les ressources stockées par les pairs. En revanche, le fait de devoir diffuser chaque requête à l ensemble des pairs pour chaque recherche tend à saturer les pairs de requêtes à traiter et donc limite fortement la capacité de passage à l échelle du système [55]. L utilisation des index locaux s associe surtout avec une adaptation du réseau hôte basée sur un overlay s appuyant sur un mécanisme d inondation [55]. En effet, l inondation, reposant sur la diffusion des messages à l ensemble des pairs afin de retrouver un pair particulier, est adaptée à ce type d index qui nécessite lui aussi de contacter l ensemble des pairs du système. En revanche, l objectif étant de trouver des ressources dans le système, il est possible de limiter l inondation en ne contactant qu un sous-ensemble de pair [80]. En effet, si une ressource donnée peut être détenue par plusieurs pairs différents, la probabilité de trouver cette ressource en ne contactant qu un sous-ensemble de pairs 32

49 2.2. Classification des différentes approches utilisées dans les systèmes P2P croit avec la taille de ce sous-ensemble. Ainsi, en limitant la longueur des chaînes de retransmission créées au cours de l inondation, on peut former un sous-ensemble centré autour du pair émetteur de la requête suffisamment grand pour que la probabilité de trouver une ressource donnée soit acceptable. En revanche, il reste une probabilité non nulle qu en limitant la portée de l inondation, une recherche puisse retourner un faux négatif [80, 109]. Les index locaux sont parfois utilisés avec des overlay utilisant des mécanismes de marche aléatoire. Contrairement à un overlay utilisant l inondation, la marche aléatoire ne retransmet pas les requêtes sur l ensemble des pairs auquel un pair donné est connecté, mais uniquement à un seul de ces pairs choisis aléatoirement. Dans le cadre d une recherche sur un index local, cela veut dire que le message est retransmis de pair en pair jusqu à trouver un pair qui possède la ressource recherchée [109]. Ainsi, plus la chaîne de retransmission devient grande, plus la probabilité d une approche basée sur la marche aléatoire trouve la ressource recherchée est grande. La chaîne de retransmission nécessaire pour trouver une copie d une ressource avec une marche aléatoire est donc beaucoup plus longue qu avec un mécanisme d inondation. En revanche, elle demande un nombre de retransmissions moins élevé [109]. Ainsi, une approche basée sur des index locaux utilisant un overlay avec un mécanisme de marche aléatoire supporte une augmentation croissante du nombre de pairs dans le système [37], au prix d une augmentation de la longueur des chaînes de retransmission des requêtes et donc du temps de réponse à celle-ci Index partagés Ce type d indexation a été proposé afin de répondre aux limites des index locaux. Dans une approche basée sur les index partagés, chaque pair maintient un index des ressources qu il met à disposition du système, et partage cet index avec les pairs auxquels il est lié [55]. Cela permet aux pairs de connaître l ensemble des ressources partagées par les pairs avec lesquels il est connecté. Quand on ajoute, supprime ou modifie une ressource détenue par un pair, les seuls index à être modifié sont le sien et celui des pairs auxquels il est connecté. Ces informations permettent aux pairs d avoir une plus grande visibilité sur les ressources présentes dans le système et ainsi orienter la propagation des requêtes aux seuls pairs susceptibles d y répondre (Fig. 2.7) [37, 55]. L avantage de cette approche est de permettre de limiter la retransmission des requêtes nécessaire à la recherche d une ressource sur le système. En effet, si la ressource recherchée est trouvée chez l un des pairs avec lequel le pair qui traite la requête est connecté, le message n est transmis qu à celui-ci [172]. En revanche, comme un index partagé est en partie composé d informations fournies par les pairs auxquels le pair qui maintient cet index est lié, ces pairs doivent transmettre l ensemble des informations sur l ajout, la suppression ou la modification d une ressource qu ils possèdent. Ainsi, la maintenance de ce type d index est plus couteuse qu un simple index local, sans pour autant remettre en cause la capacité de passage à l échelle. En effet, le nombre de liens maintenus par un 33

50 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants Figure 2.7 Diffusion d une requête sur un overlay hiérarchisé utilisant un index partagé. Les super-pairs (en rouge) ne transmettent la requête qu aux autres super-pairs et aux pairs feuilles possédant le document recherché. pair étant borné [55], le nombre de messages échangés pour maintenir la consistance d un index partagé reste limité. L utilisation d index partagés permet d améliorer les performances par rapport à une approche basée sur les index locaux de tous les overlay utilisant un mécanisme d inondation [172] ou de marche aléatoire [37]. Dans le cas d un mécanisme d inondation, l index partagé permet de réduire la portée de l inondation d un saut. En effet, au lieu de retransmettre le message à l ensemble des pairs auxquels il est connecté, quand un pair trouve la ressource recherchée dans son index partagé, il ne retransmet le message qu au pair correspondant. Dans le cas de la marche aléatoire, l utilisation d index partagés permet d étendre la visibilité des ressources mise à disposition par les pairs à chaque retransmission, ce qui diminue fortement la longueur de la chaîne de retransmission nécessaire avant de trouver une ressource dans le système [37]. Les overlay hiérarchisés reposant sur la marche aléatoire ou l inondation sont les plus adaptés à des index partagés. En effet, dans le cas d une hiérarchisation souple, les pairs qui entretiennent un grand nombre de liens avec d autres pairs du système possèdent aussi un grand nombre d index. Ainsi, retransmettre prioritairement les messages à ces pairs permet d accroitre la probabilité de retrouver une ressource dans le système [37]. Dans le cas d une hiérarchisation dure, utiliser un index partagé au niveau des super-pairs afin qu ils possèdent l index local des pair-feuilles auxquels ils sont connectés. Ainsi, les requêtes ne sont transmissent aux pair-feuilles que si ils possèdent les ressources recherchées [172]. 34

51 2.2. Classification des différentes approches utilisées dans les systèmes P2P Index distribué À l instar d un index global, dans cette approche, toutes les informations sur les ressources mises en partage sont référencées dans un même index qui est cette fois distribué sur l ensemble des pairs du système [80]. Pour ce faire, les ressources sont associées à un identifiant qui permet de définir sa position dans l espace d adressage de l index. Chaque pair maintenant une partie de cet espace d adressage, la recherche d une ressource consiste donc à trouver le pair qui a la charge d indexer celle-ci. Quand on ajoute, supprime ou modifie une ressource dans le système, la partie de l index relative à cette ressource doit alors être mise à jour. La charge est donc répartie entre les pairs en fonction du nombre de ressources indexées dans la partie de l espace d adressage dont ils sont responsable. Le principal avantage d un index distribué est de supporter le passage à l échelle [164]. En effet, l indexation des ressources étant distribuée sur l ensemble des pairs, plus le nombre de pairs participants au système augmente, plus il est possible d indexer de ressources sans pour autant augmenter l espace d indexation de chacun des pairs. De plus, contrairement aux index locaux ou partagés, les réponses aux recherches sont exactes, dans le sens où il n y a pas de possibilité de faux négatif [164]. En revanche, l index étant distribué entre les pairs, une partie de l index peut être perdu au moment du départ d un pair. Il est donc nécessaire de générer de la redondance dans l index afin de pouvoir reconstruire les parties manquantes [164]. Ce type d index est donc sensible à l attrition des pairs dans le système. Pour effectuer une recherche dans un index distribué, il est nécessaire de pouvoir retrouver dans le système le pair en charge de la partie de l index relative à la ressource visée [80]. Pour ce faire, capacité de routage des messages des overlays structurés est très efficace. En effet, dans un overlay structuré, chaque pair possède un identifiant correspondant à ces coordonnées dans un espace métrique. On utilise donc l espace d adressage de l index distribué comme espace métrique de l overlay structuré et d attribuer aux pairs la charge de l indexation des ressources en fonction de leur position dans cette espace. Ainsi, chaque ressource sera indexée par le pair qui aura l identifiant le plus proche de leur position dans l espace d adressage de l index [164]. L attribution des identifiants des ressources dans un index distribué détermine les types de recherche que l on peut effectuer. Ainsi, on peut distinguer deux approches [80], les approches avec des identifiants qui ne sont pas liés sémantiquement aux ressources et des approches avec des identifiants liés sémantiquement aux ressources Sans sémantique Dans cette approche, chaque ressource est indexée par un identifiant unique pouvant être généré par n importe quel pair du système, du moment qu il connaît suffisamment d informations sur la ressource. Pour ce faire, on utilise une fonction qui, pour un ensemble d informations données, retourne toujours une même chaîne de bits qui peut alors être utilisée comme identifiant. Cela correspond à une fonction de hachage, dont la plus utilisée à l heure actuelle, dans les systèmes P2P est SHA-1 35

52 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants [3]. Dans cette approche, pour rechercher une ressource, il est donc nécessaire de générer son identifiant à l aide de la fonction de hachage utilisée par le système. Une fois cet identifiant généré, la requête est transmise au pair qui à la charge de la partie de l index correspondante (Fig. 2.8)[164]. Ce pair retourne alors au pair émetteur de la requête l ensemble des informations de l index correspondant à cet identifiant. Figure 2.8 Répartition de l index entre les pairs en fonction de leur empreintes généré par SHA-1 dans le système Chord. Le principal avantage à l utilisation d identifiants qui ne sont pas liés sémantiquement aux ressources indexées est de permettre leur répartition uniforme dans l espace d adressage. Ainsi, en partageant uniformément la responsabilité de l espace entre les pairs, cela permet d équilibrer entre les pairs le nombre de ressources indexées dont ils ont la charge. En revanche, en l absence de lien sémantique entre les ressources indexées et leur identifiant, l expressivité des requêtes est limitée [164]. En effet, la proximité des identifiants sur l espace d adresse n est absolument pas corrélée à la similarité des ressources indexées il n est donc pas possible de faire des recherches par similarités sur ce type d index. De même, seules les recherches exactes sont possibles, dans le sens où il est nécessaire d avoir l ensemble des informations permettant de générer l identifiant pour pouvoir retrouver une ressource dans l index [164]. Afin d améliorer l expressivité des recherches sur un index distribué où les identifiants ne sont pas liées sémantiquement aux ressources, des solutions basées sur les fichiers inversés [178, 103, 133] ont été proposées. Le principe est de ne pas indexer directement les ressources dans l index distribué, mais des mots-clefs permettant de les définir [103]. Dans ce type d approches, chaque ressource est définie par un ensemble de mots-clefs. Chacun de ces mots-clefs possède un identifiant dans l index distribué de sorte que pour chacun d eux, l index contienne la liste de l ensemble des ressources identifiées par ce mot-clef ainsi que les identifiants des pairs hébergeant cette ressource. Ainsi, chaque requête contient une liste de mots-clefs pour laquelle, l index distribué retourne les listes des ressources relatives à chaque mot-clef et des pairs qui les héberges [178]. Cette approche souffre de plusieurs limites. La première réside dans le faire que pour chaque recherche, l index est 36

53 2.2. Classification des différentes approches utilisées dans les systèmes P2P interrogé un nombre de fois égal aux nombres de mots-clefs de celle-ci [103, 178]. Ce qui représente un surcoût important pour chacune des recherches effectuées sur le système. De même, cette approche nécessite que le pair qui émet la requête effectue l intersection de l ensemble des listes pour évaluer l adéquation des ressources à la requête [103, 178]. Cela revient donc à centraliser une partie non négligeable des traitements et peut poser des problèmes de support du passage à l échelle pour les requêtes contenant des mots-clefs très populaires [97] Avec sémantique Cette approche a été développée afin de permettre le support des recherches par similarités sur des index distribués. Ainsi, les identifiants des ressources sont générés de sorte à refléter les propriétés de celle-ci. Ces identifiants sont créés à partir d un espace métrique à n dimensions représentant l espace d adressage des ressources [175]. Chacune des dimensions de l espace métrique correspond à l une des caractéristiques pouvant être considérées au court de la recherche d une ressource dans le système. En effet, la position de chaque ressource sur l espace métrique est définie par ses propriétés dans chacune des caractéristiques définissant les dimensions de l espace métrique. Dans cette approche, une requête définit m propriétés des ressources recherchées, avec m inférieur ou égal à n, ainsi que soit un nombre k de ressources soit une distance maximum d. La fonction de recherche retourne soit les k plus proches points des points répondant aux propriétés définies dans la requête, soit l ensemble des points ayant une distance inférieure à d d un point répondant à ces propriétés. Ces deux types de requêtes sont respectivement appelés «recherche des K plus proches voisins» et «recherche de zone» Couche application Cette couche regroupe les fonctionnalités de haut niveau permettant d exploiter les ressources distribuées sur le système de façon transparente en s appuyant sur les primitives offertes par les deux couches précédentes. Pour ce faire, on distingue deux catégories de ressources : les données et les capacités de traitement. En effet, ces deux types de ressources possèdent des propriétés différentes, à savoir que les données peuvent être déplacées de pair en pair, alors que les capacités de traitement sont propres à chaque pair. En pratique la couche application va donc proposer deux types de fonctionnalités, le partage de données et le traitement distribué. La première permet à un pair de récupérer les données dont il a besoin alors que la deuxième permet d exploiter les capacités de traitements distribués sur le système Partage de données Ce mécanisme permet aux pairs d obtenir les données dont ils ont besoin sur le système. En effet, afin de pouvoir effectuer les traitements demandés pour la réalisation des services, 37

54 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants il faut que le pair récupère l ensemble des données nécessaires à ces traitements. Ces données pouvant être réparties sur l ensemble du système, les pairs doivent partager les données les uns avec les autres. On peut distinguer deux stratégies de partage de données, la collecte de données qui est à l initiative du pair qui a besoin des données et la diffusion de données qui est à l initiative du pair qui possède la donnée Collecte de données Cette approche consiste à permettre à un pair de récupérer, à son initiative, des données hébergées par un autre pair du système. Pour ce faire, chaque pair assume à la fois le rôle de client et de serveur [55]. La collecte de données est le modèle le plus couramment utilisé dans les systèmes P2P. Dans ce type d approches, le pair qui joue le rôle de client recherche grâce à la couche d indexation les informations lui permettant de contacter le ou les pairs qui hébergent les données qu il souhaite collecter. Ce contact peut se faire soit par l intermédiaire de la couche d adaptation du réseau hôte soit par le réseau hôte lui-même, en fonction des informations contenues dans l index. Une fois un pair qui héberge la donnée recherchée, que l on appellera pair serveur, trouvé, le pair client lui transmet une requête lui demandant de lui envoyer la ressource. Le pair serveur lui envoie la ressource soit par une connexion directe sur le réseau hôte soit par l intermédiaire de la couche d adaptation [55]. L avantage de cette approche est que seules les données nécessaires aux services sont transmises. En effet, en transférant les données «à la demande», la quantité de données transmises sera réduite à son strict minimum. En revanche, la recherche de la ressource ainsi que la «négociation» avec le pair serveur génèrent un délai avant la transmission des données [159] qui peut être problématique dans les applications temps réel. De même, chaque pair ayant un rôle serveur pour les données qu il héberge, des problèmes de passage à l échelle peuvent intervenir dans le cas de données très demandées, mais faiblement répliquées [97]. La principale optimisation proposée pour ce type d approche est de permettre la récupération des données à partir de plusieurs sources. En effet, une donnée pouvant être hébergée par plusieurs pairs distincts, la mutualisation de leur capacité d envoi permet de récupérer les données beaucoup plus rapidement. Pour ce faire, chaque donnée est fragmentée en un nombre donné de pièces [79]. Le pair client contacte alors plusieurs pairs serveur en leur demandant l envoi d une série de pièces différentes pour chacun d eux Diffusion de données Le principe de ces approches est de transmettre automatiquement des données à un groupe défini de pairs. En pratique, quand une nouvelle donnée est produite ou disponible, celle si est envoyée à l ensemble des pairs ayant souscrit à ce type de données [56]. Dans une approche par diffusion de données, chaque pair souscrit à un ou plusieurs groupes qui définiront quelles données lui seront diffusées. En effet, à chaque groupe correspond un flux de données, chaque nouvelle donnée de ce flux étant envoyée à l ensemble 38

55 2.2. Classification des différentes approches utilisées dans les systèmes P2P des membres du groupe. Pour rejoindre un groupe, un pair doit contacter un membre de ce groupe. Ce membre peut être n importe quel pair qui participe au groupe [20] ou un pair particulier qui centralise la gestion du groupe [35]. Quand un pair rejoint un groupe, la couche d adaptation du réseau hôte est modifiée de sorte que les pairs d un même groupe puissent communiquer ensemble. Quand une nouvelle donnée relative à un flux est disponible, le pair envoie la donnée soit un membre particulier du groupe qui est en charge d initier la diffusion des données dans un groupe, soit à d autres membres du groupe qu il connaît qui auront la charge de la retransmettre à leur tour à d autres membres du groupe [56]. La centralisation de la gestion de groupe possède l avantage d être simple à mettre en œuvre. En effet, il suffit pour un pair de connaître le pair responsable d un groupe pour pouvoir y souscrire [35]. De même, l intégration du pair à un groupe au niveau de la couche d adaptation du réseau hôte s en trouve facilitée, car elle revient à l intégration d un nouveau nœud à un arbre [116]. En revanche, cette centralisation implique la création d un point unique de rupture pour le mécanisme. Ainsi, si le pair responsable du groupe n est plus disponible, aucun nouveau pair ne peut intégrer le groupe. À l inverse, quand n importe quel pair d un groupe peut gérer l intégration ou le départ d un pair, le système est plus tolérant aux pannes, car cela supprime le point unique de rupture [63]. En revanche, le processus d intégration des pairs est plus lent, car il nécessite qu une partie suffisamment importante des pairs d un groupe connaissent le nouveau pair pour que son intégration soit effective. De même, centraliser l initiation de la diffusion d une donnée au niveau d un pair précis du groupe permet d optimiser le nombre de messages nécessaire à celle-ci. En effet, cela permet d utiliser une structure en arbre qui est optimisée pour la diffusion des messages [35, 20]. En revanche, cette structure est peu tolérante aux pannes, car la perte d un nœud de l arbre remet en cause la diffusion des messages à l ensemble de ses fils. À l inverse, les approches décentralisées sont plus tolérantes aux pannes, car elles ne reposent pas sur des structures en arbre, mais plus généralement sur des mécanismes de diffusions épidémiques [63, 119]. En revanche, le temps nécessaire à la diffusion des messages ainsi que le nombre de messages nécessaire sont bien plus importants que dans une approche centralisée. L utilisation de plusieurs pairs pour la gestion des groupes et l initiation de la diffusion a été proposée pour améliorer la tolérance aux pannes dans les approches centralisées [34]. L idée est d entremêler plusieurs arbres de diffusion optimisés afin que chacun d eux puisse diffuser une donnée sur l ensemble des pairs d un groupe tout en équilibrant la charge entre les pairs. Une autre optimisation a été proposée à la fois pour les approches centralisées et décentralisées de diffusion de données, elle consiste à utiliser un mécanisme de collecte de données pour compenser d éventuelles pannes ou retard dans la transmission des données [159]. L idée est qu un pair peut contacter un ou plusieurs autres pairs du groupe quand une donnée dont il a besoin ne lui a pas encore été diffusée. Cette approche n est possible uniquement si les données doivent être diffusées périodiquement, comme 39

56 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants dans des applications de vidéo ou d audio streaming Traitements distribués Ce mécanisme permet d exploiter les capacités de calculs des pairs du système pour un traitement particulier. Individuellement, les pairs possèdent une capacité de calcul limitée, ainsi pour réaliser rapidement des traitements qui demandent de grandes quantités de calculs, il est nécessaire que plusieurs pairs travaillent en parallèle dessus. La principale force des systèmes P2P dans ce type d approche est qu ils peuvent regrouper un très grand nombre de pairs et donc une très grande capacité de calcul potentielle. Deux approches, pouvant être utilisées simultanément, ont été proposées pour distribuer les traitements sur un système P2P : la délégation des traitements [14] et le traitement de flux [8]. La première consiste pour un pair à distribuer une partie des traitements à d autres pairs qui lui renverront leur résultat. Dans le deuxième cas, chaque pair est capable d exécuter une partie d un ensemble de traitements, les données nécessitant une séquence particulière de traitements pour être exploitées. Ainsi, chaque donnée est transférée de pair en pair de sorte qu à chaque saut, une partie de ces traitements soit effectuée Délégation des traitements Cette approche est principalement utilisée pour effectuer des calculs en parallèle sur des données. Son principe est de fragmenter un traitement pour le distribuer sur plusieurs pairs. Les résultats obtenus par chacun de ses pairs sont ensuite collectés afin de calculer le résultat final du traitement (Fig. 2.9)[14]. Le gain en temps de calcul apporté par ce type d approche dépend de l algorithme de traitement ainsi que du temps nécessaire pour transférer les données entre les machines [13]. Figure 2.9 Distribution des fragments de données depuis un serveur vers les pairs afin qu ils exécutent les traitements sur ces données en parallèle. 40 La délégation d un traitement est initiée par un pair qui possède l ensemble des données

57 2.2. Classification des différentes approches utilisées dans les systèmes P2P nécessaires à la réalisation de celui-ci. Ce pair découpe ces données en plusieurs fragments pouvant être traités individuellement puis les envoie à différents pairs capables d effectuer les traitements nécessaires [146, 14]. Pour trouver ces pairs, le pair initiateur utilise la couche d indexation du système si cela est nécessaire. Chacun des pairs ayant reçu un fragment de données le traite et renvoie le résultat obtenu au pair initiateur. Une fois l ensemble des résultats des fragments obtenu par le pair initiateur, celui-ci effectue un dernier traitement pour recomposer le résultat final. Selon le type de données et les traitements à effectuer, la délégation de traitement peut être une solution très efficace sur un système P2P, même comparée à des supercalculateurs 8. En revanche, si la puissance potentielle est très élevée, il existe plusieurs limites à l utilisation de la délégation des traitements. Premièrement, les traitements effectués par chaque pair pouvant être faux ou incomplets, il est nécessaire de les redonder si l on souhaite avoir des garanties sur l exactitude du résultat final. Ainsi, chaque traitement doit être fait plusieurs fois, ce qui représente une surconsommation des ressources de calculs du système [146, 14]. De même, le pair initiateur du traitement est un point unique de rupture. En effet, si ce pair sort du système entre le moment la délégation des traitements et la réception des résultats, les traitements effectués sont perdus Traitement de flux Cette approche est complémentaire à la délégation de traitement dans le sens ou elle permet de distribuer la charge d un traitement séquentiel entre plusieurs pairs. Pour ce faire, un traitement est divisé en une liste de sous-traitements devant être effectués les uns à la suite des autres [8, 132], chaque pair pouvant effectuer un nombre limité de ces sous-traitements. Les données devant passer de pair en pair, pour pouvoir êtres traitées, le traitement de flux est principalement utilisé pendant la transmission d une donnée brute depuis sa source vers une destination qui attend une donnée traitée. Un traitement de flux est initié par le pair qui possède la donnée à traiter. Ce pair recherche parmi les pairs auxquels il est lié un pair qui est en mesure d effectuer le premier sous-traitement tout en faisant progresser le message vers le pair qui doit recevoir le résultat final du traitement. Il envoie alors les données à ce pair ainsi que la liste des sous-traitements à effectuer et la destination des données traitées. Le pair qui reçoit les données effectue le premier sous-traitement et le retire de la liste. Le processus est reproduit à chaque saut jusqu à ce que le traitement ait été complètement effectué et que les données arrivent à destination (Fig. 2.10). Le traitement de flux est principalement utilisé pour distribuer des traitements sur des données brutes produites de façon décentralisée comme un réseau de capteurs [8, 132]. En effet, chaque capteur possédant des ressources de calculs limitées, distribuer le traitement au cours de la transmission des messages de pair en pair permet d équilibrer la charge 8. Foalding@home, Client statistics by OS, qtype=osstats 41

58 Chapitre 2. Analyse fonctionnelle des systèmes P2P existants Figure 2.10 Exécution des traitements sur un flux de données pendant son acheminement de pair en pair depuis sa source jusqu à sa destination. de calculs sur le système. L autre avantage de cette approche est de pouvoir être utilisée conjointement avec une approche par délégation de traitement afin de distribuer massivement un traitement sur le système. Dans ce cas, le pair qui délègue les traitements et les distribue sur plusieurs pairs ne reçoit pas les résultats. En effet, ces derniers sont transmis aux pairs suivants jusqu à ce qu ils atteignent tous le pair destination qui recomposera alors le résultat final. Comme pour la délégation de traitement, pour obtenir des garanties sur les résultats, il est nécessaire de redonder les calculs. Pour ce faire, le pair qui initie le traitement envoie les données ainsi que la liste de sous-traitements à plusieurs pairs de sorte que le pair cible des données traitées reçoive les résultats de différentes chaînes de traitements [76]. 2.3 Conclusion Notre découpe des systèmes P2P en plusieurs couches indépendantes nous permet de capter la très grande diversité des systèmes P2P qui ont été proposés à ce jour. En effet, notre approche permet de mieux comprendre les particularités de systèmes tel que Freenet [40] ou le système proposé dans [105] que les états de l art précédent échouaient à classer. L un des avantages de notre classification est qu elle permet de visualiser une très grande partie des systèmes simples qui peuvent être développés à partir des mécanismes présentés dans la littérature. En effet, chaque couche fonctionnelle étant indépendante, il est possible de combiner les approches présentées dans chacune d elle pour former un système. Ainsi, en ne considérant que les systèmes n utilisant qu une seule approche pour chaque couche fonctionnelle, on obtient déjà 140 combinaisons. Or, même en se limitant qu aux combinaisons des couches d adaptation du réseau hôte et d indexation pour un soucis de lisibilité, constate dans le tableau 2.1 que très peu de ces combinaisons ont fait l objet d une implémentation. Au vu de l ensemble des combinaisons possibles, on peut supposer que l on peut d obtenir un système P2P adapté à un contexte donné en choisissant les approches les plus pertinentes au niveau de chaque couche fonctionnelle, puis d adapter ses approches en 42

59 2.3. Conclusion Table 2.1 Exemples de systèmes P2P existant pour chaque combinaison d approches d adaptation du réseau hôte et d indexation Serveur Overlay Overlay hiérarchique Overlay Overlay hié- d adressage simple structuré rarchique structuré Index global centralisé Napster [55] Bittorrent [79] Index global répliqué PlanetP [42] Index locaux Gnutella 0.4 Structella [55] [33] Index partagés GIA [37], Gnutella 0.6 [55] Index distribués Freenet [40] Chord [151], Cacophony sans sémantique Pastry [135] [62] Index distribué SIMPEER SWAM [19], avec sémantique [54] M-Chord [125] fonction du besoin. Pour qu une telle méthode de développement de système P2P soit possible, il est nécessaire d étudier préalablement les performances et limites des approches possibles au niveau de chacune des couches fonctionnelles. À partir de cette étude, il sera alors possible de créer une grille d analyse permettant de déterminer quelle approche est la plus adaptée en fonction des besoins et ainsi pouvoir composer un système pour un contexte applicatif donné. 43

60

61 CHAPITRE 3 PROPOSITION D UNE GRILLE D ANALYSE POUR L AIDE À LA CONCEPTION DES SYSTÈMES P2P Dans ce chapitre, nous présentons une grille d analyse dont le but est de permettre, à partir des besoins relatifs à un contexte applicatif donné, de définir les approches les plus adaptés pour composer un système P2P. Nous partons donc des différentes propriétés fonctionnelles pouvant être développées au niveau de chacune des couches d un système P2P, pour classer les performances des différentes approches possibles. Ainsi, après avoir présenté les principes de notre nouvelle analyse, nous dégageons, au niveau de chaque couche, les propriétés qui peuvent être développées et classons en fonction de celles-ci les différentes approches existantes. Nous finirons cette analyse par la présentation des synergies qui peuvent exister entre des approches de différentes couches et ainsi apporter à notre grille une vision globale du système que la découpe en couches fonctionnelles ne permet pas de considérer. 3.1 Analyse des propriétés fonctionnelles et non fonctionnelles Notre objectif est de créer une grille d analyse qui permette de déterminer les approches les plus adaptés pour répondre aux besoins d un contexte applicatif donnée et ainsi permettre aux développeurs de composer un systèmes P2P optimiser pour répondre à ces besoins. Pour ce faire, il est nécessaire d analyser les propriétés fonctionnelles et non-fonctionnelles des différentes approches qui ont été dégagées au chapitre précédent, afin d évaluer leur adéquation avec les besoins associés à un contexte. 45

62 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Pour réaliser cette analyse, nous déterminons les différentes fonctionnalités qui peuvent être développées au niveau de chacune des couches du système. À partir de ces fonctionnalités, nous distinguons les propriétés non-fonctionnelles qui peuvent y être appliquées, comme la tolérance aux pannes, l exactitude des recherches ou la latence des transmissions. Pour chacune des possibilités ainsi dégagées, nous analysons l adéquation des approches existantes afin de déterminer celles qui sont les plus adaptées. De plus, le choix d une approche peut être aussi impacté par des contraintes relatives au système que l on souhaite développer. En effet, un système de calcul distribué ne pourra, par exemple, pas déplacer des ressources de calculs entre les pairs, car celles-ci sont intrinsèquement liées aux pairs eux-mêmes. Ainsi, en fonction de ces contraintes, certaines approches ne peuvent simplement plus être utilisées, alors que d autres ne possèdent un intérêt que dans un environnement fortement contraint. Ainsi, l analyse suivante est découpée par rapport aux trois couches fonctionnelles que nous avons définies dans le chapitre précédent. L analyse commence par les couches les plus hautes afin de prendre en compte les besoins les plus généraux en premier. En effet, la couche application servant à prendre en charge les fonctionnalités de haut niveau qui composeront l application finale, les approches retenues à cette couche guident les choix qui pourront être faits au niveau des couches plus basses du système. Chacune des couches est ensuite découpée en fonctionnalités et/ou propriétés. Pour chacune d elles, nous dégageons les approches les plus adaptées et les éventuelles dépendances et incompatibilités qui en découlent. Nous analysons ensuite l adéquation des approches possibles entre les différentes couches afin de discriminer plus finement les approches restantes. 3.2 Couche application La couche application fournit aux développeurs les primitives nécessaires pour créer les fonctionnalités et services du système. La particularité de cette couche est d offrir un choix de fonctionnalités qui serviront à créer les services finaux du système plutôt que des propriétés pour une fonctionnalité précise. En effet, les couches d indexation et d adaptation du réseau hôte ne fournissent qu une fonctionnalité, dont les propriétés, peuvent varier. Les deux principales fonctionnalités fournies par la couche application sont le partage de données et la distribution des traitements. Chacune de ses fonctionnalités peut développer des propriétés différentes en fonction du contexte qui génèreront de nombreux besoins sur les couches suivantes. 46

63 3.2. Couche application Le partage de données Le partage de données est la fonctionnalité essentielle d un système P2P. En effet, de par la nature distribuée des systèmes P2P, tous les services ou fonctionnalités pour l utilisateur final passent obligatoirement par un échange de données entre des pairs du système. Les principales propriétés pouvant impacter le choix d une approche de partage de données sont les contraintes de latence et l absence de connaissances à priori des pairs destinataires des données Contraintes de latence Pour répondre aux besoins de certaines applications temps réel le partage de données peut avoir des contraintes de latences. En effet, dans les applications comme le streaming audio ou vidéo [159] ou de visio-conférence [22], les données doivent être transmisses avec une latence suffisamment faible pour ne pas altérer la qualité du contenu. Les approches par collectes de données ne sont pas adaptées avec cette contrainte. En effet, dans ces approches, le pair ayant besoin d une donnée doit contacter un pair la possédant pour la récupérer. Ce mécanisme nécessite donc que le pair demandeur initie chaque transmission de données, ce qui augmente fortement la latence. Ainsi, l approche la plus efficace est la diffusion de données qui permet, une fois qu un pair est inscrit comme destinataire d un type de données de les recevoir sans nécessiter d échanges pour initialiser les transmissions Absence de connaissances à priori sur les destinataires des données Dans certains systèmes, il est possible de déterminer à priori les pairs qui doivent recevoir une donnée, par exemple dans les réseaux de capteurs [143] ou les systèmes de streaming [159]. Si cette connaissance doit exister, elle peut être maintenue de différentes façon, comme dans la structure d un arbre de diffusion [35] et ne nécessite donc pas qu un pair seul la maintienne. La précision de cette connaissance peut varier en fonction des systèmes. En effet, elle peut correspondre à une liste précise de pairs, comme dans le modèle Publish/Subscribe [161] aussi bien qu à un ensemble plus diffus correspondant à tous les pairs partageant certaines propriétés. Le principe est d avoir suffisamment d informations pour permettre au système de diriger la transmission des données aux pairs concernés. En effet, sans ces informations, le seul moyen pour diffuser une donnée aux pairs qui en ont besoin est de la transmettre à l ensemble des pairs du système. Cela représente donc un coût prohibitif en nombre de messages transmis et donc en consommation de ressources réseau. En l absence de connaissances à priori sur les destinataires des données, l approche la plus adaptée est la collecte de données. En effet, dans ces approches, les transmissions de données se font à l initiative du pair demandeur, elle ne nécessite donc aucune connaissance préalable sur les destinataires des données [55]. En revanche, la diffusion de données n est 47

64 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P pas une solution adaptée en l absence de ces connaissances. En effet, il faudrait diffuser les données à l ensemble des pairs présents dans le système pour que les données puissent atteindre les pairs qui en ont besoin Distribution des traitements De par leur nature distribuée, les systèmes P2P sont composés d un grand nombre de machines. Ainsi, même si la puissance de calcul totale de ces systèmes peut être particulièrement élevée, les capacités de calcul de chaque pair sont souvent limitées. Pour pouvoir gérer des traitements lourds, il est donc nécessaire de les distribuer entre les pairs pour réduire le temps nécessaire pour les effectuer. En effet, si certains calculs légers peuvent être effectués en local, des calculs plus lourds peuvent prendre un temps prohibitif ou tout simplement être impossibles à réaliser avec les ressources disponibles au niveau du pair. La distribution de traitements n est donc nécessaire que si la réalisation des besoins fonctionnels nécessite des traitements qui ne peuvent être effectués par un seul pair. On distingue deux propriétés permettant de guider le choix de l approche de distribution de traitements, les contraintes au niveau du temps de calcul et le taux de parallélisation du traitement Contraintes au niveau du temps de calcul Certains systèmes nécessitent que des traitements soient réalisés en temps limité et qu aucun pair ne possède la puissance de calcul nécessaire en local pour les réaliser. Il est alors nécessaire de mutualiser les ressources de calcul de plusieurs pairs pour respecter ces contraintes. La seule approche permettant de limiter le temps de calcul dans un système P2P est la délégation des traitements. En effet, le traitement de flux permettant de distribuer un traitement séquentiel, il ne permet que de distribuer la charge de calcul entre les pairs, mais pas de réduire le temps nécessaire pour le réaliser [8]. En revanche, en parallélisant [13] un traitement sur plusieurs pairs, il est possible de réduire le temps nécessaire pour le réaliser Taux de parallélisation du traitement élevé Chaque traitement peut être parallélisé dans une limite donnée qui lui est propre. En effet, tout traitement possède au moins une partie qui doit être traitée séquentiellement et ne peut donc pas être parallélisé [13]. Cette limite détermine donc le gain que l on peut obtenir en terme de temps de calcul en parallélisant les traitements. En effet, plus un traitement peut être parallélisé, plus le système peut affecter de pairs pour la réalisation de ce traitement. En revanche, si la partie parallélisable d un traitement est très faible, le temps nécessaire à la distribution du traitement peut être supérieur aux gains de temps obtenus par leur parallélisation. De plus, la partie séquentielle du traitement peut être 48

65 3.2. Couche application trop importante pour qu un pair puisse la réaliser seul. Ce traitement séquentiel doit donc lui aussi être distribué sur plusieurs pairs pour pouvoir être réalisé. Ainsi, plus le taux de parallélisation du traitement est élevé, plus les approches par délégation de traitements sont intéressantes. À l inverse, si la quantité de traitements séquentielle est trop élevée pour qu un pair seul puisse les réaliser, il est nécessaire d utiliser une approche par traitement de flux pour distribuer la charge de ces traitements entre les pairs Grille d analyse de la couche application À partir des analyses précédentes sur les propriétés des fonctionnalités pouvant être développées au niveau de la couche d indexation, nous en déduisons les tableaux 3.1 et 3.2. Le premier tableau met en évidence les incompatibilités entre les propriétés pouvant être obtenues. Par exemple, il n est pas possible de réduire le temps de calculs d un traitement si ce traitement à un faible taux de parallélisation. Le tableau 3.2, présente l adéquation des différentes approches pouvant être utilisées au niveau de la couche application avec les propriétés des fonctionnalités que nous avons dégagées. Nous avons opté pour une comparaison qualitative plutôt que quantitative pour effectuer cette comparaison. En effet, l existence d un très grand nombre de systèmes réalisant les fonctionnalités de chacune des approches rend difficile de déterminer des bornes communes de performances pour chacune d elles. De même, les choix des approches au niveau des couches inférieurs du système peuvent influencer grandement les résultats d une analyse quantitative, et il est impossible de quantifier exactement ses influences sans tester chacune des combinaisons possibles. En revanche, une simple analyse qualitative, comme notre tableau 3.2 permet de mettre en évidence que chaque approche issue de l état de l art du chapitre 3 correspond bien à des besoins et contraintes particuliers. Table 3.1 Incompatibilités des besoins et contraintes dégagés pour la couche application Latence Absence de Contraintes de Faible parallélisation connaissances temps de calcul du à priori traitement Latence NA Incompatible Absence de Incompatible NA connaissances à priori Contraintes de NA Incompatible temps de calculs Faible parallélisation Incompatible NA du traitement 49

66 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Table 3.2 Types d approches associées aux besoins et contraintes dégagés Latence Absence de Contraintes de Faible parallélisation connaissances temps de calcul du à priori traitement Collecte de données ++ NA NA Diffusion de données ++ NA NA Délégation de NA NA ++ traitements Traitements de NA NA ++ flux 3.3 Couche d indexation L objectif de la couche d indexation est de retrouver les ressources distribuées sur le système. Ainsi, les propriétés qui définiront les approches utilisées au niveau de la couche d indexation seront principalement relatives aux besoins du système et de ceux définis au niveau de la couche application. En effet, il est nécessaire de définir les ressources que la couche d indexation devra permettre de retrouver ainsi que les types de résultats attendus afin de pouvoir déterminer les nouveaux besoins qui peuvent en découler. De plus, la couche d indexation doit gérer les informations relatives aux ressources indexées que nous appellerons métadonnées. En effet, le principe même de la couche d indexation est de créer une structure contenant les informations définissant les ressources disponibles sur le système. La nature de ces informations définit les capacités de recherche du système dans le sens où seules ses informations sont prises en compte pour retrouver une ressource. L une des propriétés associées à ces métadonnées est la capacité du système à gérer leur placement. En effet, pour des raisons de confidentialité, il peut être préférable que ces métadonnées ne soient pas distribuées, ce qui détermine fortement le type d approche pouvant être retenue. Enfin, le passage à l échelle et la tolérance aux pannes qui sont des propriétés fondamentales des systèmes P2P sont en partie déterminés au niveau du choix de l approche retenue au niveau de la couche d indexation. Ainsi, ses besoins de se retrouvent à la fois au niveau de la couche d indexation et au niveau de la couche d adaptation du réseau hôte. Ainsi, les différentes propriétés relatives à la couche d indexation que nous avons donc retenues sont le passage à l échelle, la tolérance aux pannes, le schéma de recherche documentaire, le type de résultat obtenu et le placement des métadonnées. 50

67 3.3. Couche d indexation Passage à l échelle Les systèmes P2P servant à mutualiser les ressources mises en partage par les pairs, on considère que chaque pair apporte des ressources devant être indexées. Ainsi, dans le cas de la couche d indexation, le support du passage à l échelle est déterminé par la croissance du nombre d entrées dans l index hébergé par un pair, en fonction du nombre de pairs présents dans le système. Un pair ne pouvant posséder plus de ressources qu il ne peut en indexer, les approches basées sur les index locaux supportent automatiquement le passage à l échelle. Pour la même raison, les approches basées sur les index distribués supportent le passage à l échelle, car il n est pas possible que l ensemble des ressources devant être indexées excède la capacité d indexation cumulée de l ensemble des pairs présents dans le système [40, 66]. Les index partagés peuvent avoir des problèmes de passage à l échelle, car les pairs indexent à la fois leur ressource et les ressources détenues par les pairs auxquelles ils sont liés. Ainsi, une telle approche ne passe pas à l échelle si les pairs du système possèdent des quantités de ressources telles qu ils ne peuvent pas en indexer plus que celles qu ils hébergent. Or le coût d indexation étant beaucoup plus faible que le coût d hébergement d une ressource, une telle situation est presque impossible. On considère donc les approches basées sur les index partagés supportent le passage à l échelle. En revanche, les approches basées sur un index global, qu elles soient centralisées ou répliquées ne supportent pas le passage à l échelle [55, 42]. En effet, dans ces approches, au moins un pair doit indexer l ensemble des ressources présentent dans le système. Or la capacité d indexation d un pair étant limitée, il est possible d atteindre cette limite avec l augmentation du nombre de pairs présents dans le système Tolérance aux pannes Au niveau de la couche d indexation, la tolérance aux pannes se traduit par la probabilité de perdre des métadonnées composant l index au moment de la panne d un pair, alors que la ressource est toujours présente dans le système. En effet, la perte de métadonnées relatives à une ressource encore présente dans le système peut entrainer des faux négatifs des résultats d une requête. Les approches basées sur les index locaux et les index distribués où les ressources sont hébergées avec les métadonnées qui les décrivent tolèrent complètement les pannes des pairs. En effet, dans ces deux cas, la perte des métadonnées est corrélée avec la perte des ressources qu elles décrivent. De même, les index partagés tolèrent aussi complètement les pannes, car il faut qu un pair ne soit plus lié à aucun autre pair pour qu une de ses ressources ne soit plus présente sur aucun des index partagés. Cette situation le déconnectant du système, elle rend donc aussi la ressource indisponible. Dans les approche basées sur des index distribués, la panne d un pair peut entrainer la perte d une partie de l index sur des ressources encore présentes dans le système [66]. Pour 51

68 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P limiter ce risque, les parties de l index détenues par chaque pair doivent être redondées sur d autres pairs afin que les métadonnées ne soient pas perdues [66]. Si cette redondance permet à ces approches d être tolérantes aux pannes, elles peuvent limiter les capacités de passage à l échelle du système. En effet, si une fois redondé, si la taille de l index excède la capacité d indexation cumulée de l ensemble des pairs présents dans le système, alors le système ne peut plus supporter le passage à l échelle. De même, une approche basée sur un index global répliqué est tolérante aux pannes, car l ensemble de l index est répliqué sur tous les pairs présents dans le système. Ainsi, la redondance de l index rend impossible la perte de métadonnées due à une panne [42]. Enfin, les approches basées sur un index global centralisé ne sont pas tolérantes aux pannes. En effet, si le serveur central n est plus disponible, l index est totalement perdu et rend ainsi toutes recherches sur le système impossible Schéma de recherche Le système de recherche de ressources dans les systèmes P2P peuvent offrir différentes possibilités à la couche application. En effet, le système de recherche peut avoir des propriétés différentes comme la possibilité d effectuer une recherche sur une ressource précise ou de rechercher des ensembles de ressources répondant à certains critères. On distingue deux types de schémas de recherche pouvant être offerts par la couche d indexation, les recherches exactes et les recherches floues Recherches exactes Ce type de schéma de recherche permet de retrouver une ressource particulière indexée par le système. Ainsi, à partir de la définition exacte d une ressource que l on cherche, ce type de recherche retourne l ensemble des informations relatives à cette ressource, comme les coordonnées des pairs qui l hébergent. Ainsi, il est donc nécessaire de pouvoir définir exactement une ressource pour retrouver les informations qui s y rapportent. Dans ces systèmes, la description exacte de la ressource est la principale métadonnée utilisée par le mécanisme de recherche. Une recherche exacte ne peut donc être utilisée que si les pairs peuvent définir exactement les ressources qu ils recherchent et que cette description ne correspond qu à une seule ressource. Cela peut donc correspondre à une empreinte de hachage [3] d une ressource donnée. Il est aussi possible de définir une description exacte d une ressource qui ne serait valable que pour le système. Ainsi, le nom d une ressource peut être considéré comme une description exacte si toutes les ressources possèdent des noms différents. Il serait alors possible de retrouver une ressource à partir du nom de celle-ci [66]. Tout index sans sémantique permet d effectuer des recherches exactes. En terme de performance, les approches les plus adaptées sont celles basées sur un index global ou un index distribué, car ces approches ne nécessitent pas de contacter un grand nombre de 52

69 3.3. Couche d indexation pairs pour effectuer une recherche sur l ensemble des ressources présentes dans le système. En effet, même dans le cas d un index distribué, il est théoriquement possible de répondre à une requête en ne contactant que le pair responsable de la partie de l index correspondante Recherches floues Ce type de recherches permet de retrouver des ensembles de ressources répondants à des critères définis dans la requête. Chaque ressource doit être décrite à l aide de métadonnées afin que le système puisse vérifier l adéquation de chaque ressource avec les critères décrits dans la requête. Ainsi, les différents types de recherches floues sont définis par le type de métadonnées servant à décrire les ressources présentes dans le système. On distingue deux principaux types de métadonnées pouvant être appliqués aux ressources : des mots-clefs et des valeurs relatives à des propriétés Par mots-clefs Dans une recherche floue par mots-clefs, chaque ressource est associée à un ensemble de mots servant à la décrire. Ainsi, une requête est composée d un ensemble de mots-clefs qui est comparé à ceux associés aux ressources afin de déterminer si elles répondent à la requête. Les modalités d affectation des mots-clefs dépendent du système que l on souhaite créer. En effet, elles affectent les capacités de recherche dans le sens où elles définissent comment les ressources seront décrites. Ainsi, une affectation automatique des mots-clefs limitera la façon de décrire une ressource à ce qu un algorithme peut déduire d une ressource donnée, alors qu une affectation humaine, comme dans une folksonomie [70], permettra de prendre en compte différents points de vue sur la ressource. La recherche floue par mots-clefs est l approche la plus générique pour la recherche de ressource car elle ne fait aucune supposition quant à la nature des ressources indexées par le système. En effet, il est possible d affecter des mots-clefs à n importe quel type de ressources, même si elles sont de natures très différentes, comme des images, du texte ou des vidéos. En revanche, la façon d associer ces mots-clefs aux ressources va déterminer le comportement du système de recherche. Pour utiliser cette approche, il est nécessaire d avoir un système permettant d affecter des mots-clefs aux ressources. En revanche, la nature de ce système peut aussi bien être automatique que basée sur une intervention humaine. Il est donc nécessaire que cette nouvelle fonctionnalité soit prise en compte à partir de la couche application. Les index globaux [42], locaux ou partagés [55] permettent de gérer directement ce type de recherche. Les index distribués nécessitent d être adaptés pour prendre en charge ce type de recherche, mais peuvent permettre d obtenir dans certains cas des performances similaires voir éventuellement supérieur aux autres approches [103, 166] Par propriétés Dans une recherche floue par propriétés, chaque ressource est définie par des valeurs relatives à un ensemble propriétés prédéfinies. Ainsi, il faut que 53

70 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P chaque ressource indexée dans le système puisse avoir une valeur pour chaque propriété qui aura été retenue. Le choix de ses propriétés détermine donc les types de ressources pouvant être gérés par le système. Pour effectuer une recherche par propriétés, on définit pour une requête un ensemble de propriétés que les ressources doivent posséder et le système recherche les ressources qui y correspondent. Les recherches floues par propriétés permettent des recherches complexes comme les recherches par similarité. Elles sont donc adaptées pour retrouver des ensembles de ressources possédants des propriétés similaires. En revanche, elles ne peuvent s appliquer qu à des ressources de même nature pour lesquelles il est possible de définir des propriétés communes. Ainsi, ces approches ne peuvent s appliquer qu à des systèmes n indexant que des ressources de même nature. On ne peut donc pas appliquer une approche par propriétés si le système doit indexer des ressources hétérogènes. De même, il est difficilement envisageable de pouvoir enrichir les propriétés définissant les ressources indexées, car il faudrait ré-évaluer chaque ressource déjà présente dans le système en fonction de ces nouvelles propriétés. Il est donc nécessaire que les propriétés permettant de définir les ressources soient définies à la création du système. Les index distribués avec sémantique sont les approches les plus adaptées pour réaliser ce type de système, avec des approches comme M-Chord [125] ou SWAM [19]. Il existe aussi des approches basées sur les index partagés [54, 55] pouvant être efficace le système est composé de pairs possédant des ressources très hétérogènes. Enfin, les index globaux centralisés sont aussi très efficaces [55] pour ce type d approche, même si ils limitent les capacités de passage à l échelle du système Résultat des recherches Un autre ensemble de propriétés importantes pour la couche d indexation est le résultat des recherches. En effet, le système peut nécessiter que l ensemble des ressources répondant à une requête soit présent dans le résultat de celle-ci alors que certains systèmes ne nécessitent qu un nombre suffisant de résultats. De même, certains systèmes peuvent tolérer des types d erreurs dans les résultats obtenus pour une recherche, comme des faux positifs ou des faux négatifs Complétude Certains systèmes nécessitent que l ensemble des ressources répondant à une requête soit présent dans le résultat de celle-ci afin que ce résultat soit complet, comme dans les recherches à facette [24]. Si ce besoin est essentiel dans le cas de recherches exactes, il n est pas forcement nécessaire pour les systèmes de recherches floues où un nombre minimum de résultats peut suffire à satisfaire aux besoins en recherche de ressources. Afin de pouvoir assurer la complétude des résultats obtenus, il est nécessaire que la 54

71 3.3. Couche d indexation recherche s effectue sur l ensemble de l index des ressources présentes dans le système. Si cela est théoriquement possible sur n importe quel type d index, les index globaux, qu ils soient centralisés, répliqués ou distribués permettent plus facilement d atteindre la complétude des résultats que les index locaux ou partagés. En effet, pour ces deux dernières approches, il est nécessaire de pouvoir vérifier le contenu des index de l ensemble des pairs présents dans le système pour pouvoir garantir la complétude des résultats, ce qui peut devenir rapidement très coûteux en nombre de messages à transmettre et donc en ressources réseau Tolérance aux erreurs De par la nature fortement distribuée des systèmes P2P, le résultat d une recherche peut contenir des erreurs. Nous considérerons ici deux types d erreurs que sont les faux négatifs et les faux positifs Faux négatifs Ce type d erreur correspond au fait que le système n arrive pas à trouver une ressource présentes dans le système, soit parce qu elles ne sont pas indexées, soit parce que le système échoue à transmettre la requête aux pairs qui l index. La tolérance aux faux négatifs peut être considérée comme un cas particulier de la complétude des résultats. En effet, certains systèmes peuvent ne pas nécessiter que les résultats d une recherche soient complets, mais devoir garantir qu une ressource rare sera retrouvée si elle fait l objet d une recherche. C est par exemple le cas des recherches de type k meilleurs [152]. Comme pour la complétude, le seul moyen d éviter les faux négatifs est que la recherche s effectue sur l ensemble de l index des ressources présentes dans le système. Ainsi, les index globaux centralisés, répliqués et distribués sont les plus adaptés pour développer cette propriété. Dans le cas d index locaux et partagés, il est nécessaire que les index de l ensemble des pairs soient vérifiés pour permettre cette propriété Faux positifs Dans certains cas, le système peut intégrer dans ses réponses des ressources qui ne sont plus disponibles dans le système. En effet, un faux positif correspond au cas où l index contient des ressources qui ont disparu du système, comme dans le cas de la panne du pair qui l héberge. Ce type d erreur peut être dommageable pour des systèmes servant à recenser des ensembles de ressources présentes à un instant donné. Pour éviter le risque de faux positifs dans les résultats, il faut que les informations contenues dans l index soient à jour. Ainsi, pour garantir l absence de faux positifs, il faut que les métadonnées qui forment l index soient hébergées avec les ressources elles-mêmes, comme c est le cas avec des index locaux. Dans le cas contraire, c est la fréquence des mises à jour des métadonnées qui déterminera la probabilité de faux positif dans les résultats. 55

72 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Ainsi, plus cette fréquence sera élevée, plus le risque de faux positif sera faible, mais plus le coût de maintenance, en termes de messages échangés, sera élevé Placement des métadonnées Si les métadonnées servent à décrire les ressources présentes sur le système, leur hébergement par les pairs peut être décorrélé de celui des ressources elles-mêmes. Ainsi, dans certains cas, il peut être intéressant de distribuer les métadonnées indépendamment des ressources afin de modifier le comportement du mécanisme de recherche. On distingue trois propriétés associées à l hébergement des métadonnées : la confidentialité, le nomadisme des ressources et le coût de maintenance La confidentialité Comme tout environnement distribué, la question de la confidentialité des informations relatives à chaque pair présent dans le système se pose. En effet, la mutualisation des ressources des participants, qui est le principe même d un système P2P, implique qu il soit possible de retrouver une ressource présente dans le système. Or le besoin de confidentialité impose qu il ne soit pas possible, pour un pair non autorisé, de trouver des informations sur les ressources mises en partage par un autre pair du système. La seule approche permettant d atteindre cette propriété est l utilisation d index locaux. En effet, avec ce type d indexation, seul le pair hébergeant une ressource a connaissance de ce fait. Ainsi, il est libre de répondre aux requêtes qu il reçoit, en fonction des droits d accès aux ressources des pairs émetteurs des requêtes. Un index global centralisé peut aussi répondre au problème de confidentialité à la condition que le serveur central soit hébergé par un tiers de confiance garantissant la confidentialité des informations qui lui sont envoyées Nomadisme des ressources Certaines ressources sont intrinsèquement liées aux pairs qui les hébergent, comme c est le cas de ressources de calculs ou de stockage, alors que d autres peuvent être déplacés ou dupliqués, comme des données numériques. Dans ce dernier cas, la problématique de placement des métadonnées peut être retournée en une problématique de placement des ressources. En effet, dans des approches d index distribué, le placement des métadonnées est imposé de sorte à faciliter la recherche dans l index [40, 66, 19]. Ainsi, le seul moyen d héberger les métadonnées avec les ressources qui y correspondent est alors de déplacer les ressources au niveau des pairs hébergeant les métadonnées [40, 97]. Le nomadisme des ressources correspond donc à la capacité du système à pouvoir déplacer les ressources entre les pairs et dépend donc de la nature des ressources que le système aura à traiter. Si les ressources ne peuvent pas être déplacées, il ne sera pas possible de garantir l absence de résultats faux positif dans des index distribués. 56

73 3.3. Couche d indexation Coût de maintenance Pour garantir la précision des métadonnées, le système doit les maintenir à jour. Les systèmes P2P étant de nature dynamique, les métadonnées doivent donc être modifiées afin de refléter les changements qui peuvent intervenir. Que les modifications des données soient effectuées de façon réactive ou proactive, il est nécessaire de périodiquement vérifier que les métadonnées sont à jour afin de tenir compte des éventuelles pannes survenues au niveau des pairs. La maintenance de l index impacte la probabilité de faux positifs d une recherche. Ainsi, plus la fréquence des mises à jour de l index sera élevée, plus la probabilité de faux positifs sera faible. En revanche, une fréquence de mises à jour élevée nécessitera des échanges réguliers de messages entre les pairs et donc un coût de maintenance important. Le coût de maintenance varie en fonction de l approche d indexation retenue. En effet, si les métadonnées sont hébergées par le même pair que les ressources qu elles décrivent, le coût de maintenance sera nul car aucun message ne devra être transmis pour les mettre à jour. À l inverse, si les métadonnées ne sont pas hébergées par les pairs qui hébergent les ressources, les pairs devront échanger des messages pour maintenir l index à jour [66]. Ainsi, plus le placement des métadonnées sera décorrélé de l hébergement des ressources, plus le coût de maintenance de l index sera élevé. Les approches basées sur les index locaux et les index distribués pour lesquelles les métadonnées sont hébergées par les pairs qui hébergent les ressources ne possèdent pas de coût de maintenance de l index. Les approches basées sur les index partagés et un index global centralisé possèdent un coût de maintenance faible, car les messages de maintenance ne sont transmis qu à un seul saut. Enfin, les approches basées sur un index global répliqué [42] et sur un index distribué où le placement des métadonnées est décorrélé de celui des ressources possèdent le coût de maintenance le plus élevé, car les messages de maintenance doivent être retransmis de pair en pair Grille d analyse de la couche d indexation À partir de cette étude sur les propriétés relatives aux fonctionnalités de la couche d indexation, nous en déduisons le contenu des tableaux 3.3 et 3.4. Dans le premier tableau, nous mettons en évidence les incompatibilités entre les différentes propriétés pouvant être développées dans le système. En effet, un système ne peut, à la fois, permettre le nomadisme des ressources et garantir la confidentialité des données. On constate d ailleurs que les incompatibilités sont peu nombreuses entre les propriétés pouvant être développées, d autant qu il est toujours possible de faire cohabiter deux approches d indexation dans un même système voir sur une même approche d adaptation du réseau hôte. 57

74 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Passage à l échelle Tolérance aux pannes Recherche exacte Par motsclefs Par propriétés Compétude Faux négatif Faux positif Confidentialité Nomadisme Coût de maintenance Passage à l échelle NA Table 3.3 Incompatibilités des besoins et contraintes dégagés pour la couche application Tolérance aux pannes Recherche exacte Par motsclefs Faux négatif Faux positif Par propriétés Compétude Confidentialité Nomadisme Coût de maintenance NA NA Incompatibltible Incompa- Incompatibltible NA Incompa- Incompatible Incompatible NA NA Obligatoire NA Incompatible Incompatible NA NA Incompatible Incompatible NA NA 58

75 3.3. Couche d indexation Dans le tableau 3.4, on constate que chaque approche représente un compromis en termes de propriétés. Ainsi, aucune approche n est meilleure qu une autre dans l absolu et leur utilisation dépend donc exclusivement des besoins et du contexte d application. On peut aussi remarquer le cas particulier du besoin de nomadisme qui n est pas applicable à de nombreuses approches. En effet, dans le cas d index globaux qu ils soient centralisés ou répliqués, le nomadisme reviendrait à ce que chacun des pairs hébergeant l index global doivent aussi héberger l ensemble des ressources, ce qui reviendrait à un système totalement centralisé en local ou à un système Clients/Serveur. De même, dans le cas d index locaux, le nomadisme fait partie intégrante de cette approche vu que chaque pair n indexe que les ressources qu il héberge. Enfin, le cas d index partagés, le nomadisme reviendrait à une réplication de toutes les ressources entre deux pairs partageant un lien, ce qui revient générer de la réplication tout en perdant les avantages des index partagés par rapport aux index locaux. Ainsi, le nomadisme n a de sens qu avec des index distribués. Table 3.4 Types d approches associées aux besoins et contraintes dégagés Index global Index global Index locaux Index partagés index distribué index distribué centralismantiqumantique répliqué sans sé- avec sé- Passage à l échelle Tolérance aux pannes Recherche exacte Par motsclefs Par propriétés Compétude Faux négatif Faux positif Confidentialité + ++ Nomadisme NA NA NA NA Coût de ++ + maintenance 59

76 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P 3.4 Couche d adaptation du réseau hôte La couche d adaptation du réseau hôte gère les communications entre les pairs du système. La principale fonctionnalité de cette couche est donc de permettre à un pair de retrouver un autre pair dans le système et de leur fournir les informations nécessaires pour qu ils puissent communiquer ensemble. Les différentes approches existantes pour l adaptation du réseau hôte permettent donc d obtenir des propriétés différentes pour ce mécanisme de découverte des pairs dans le système. De plus, la couche d adaptation du réseau hôte impacte de nombreuses propriétés non fonctionnelles du système, comme la capacité de passage à l échelle, la tolérance aux pannes, la latence des transmissions ou encore la non-imputabilité des actions dans le système. La prise en compte de ces propriétés permet donc de discriminer plus précisément les approches les plus adaptées pour le système que l on souhaite créer. Le passage à l échelle et la tolérance aux pannes sont des propriétés non fonctionnelles qui existent aussi au niveau de la couche d indexation. En effet, la couche d indexation et la couche d adaptation d un réseau hôtes peuvent toutes deux influencer les performances d un système par rapport à ces deux propriétés, mais pour des raisons différentes. De même, la latence est une propriété que l on retrouve aussi au niveau de la couche application, mais est considérée ici selon un autre point de vue. Ainsi, pour une approche identique au niveau de la couche d adaptation du réseau hôte, une approche par collecte de données aura toujours une latence plus importante qu une approche par diffusion. Nous considérerons donc les propriétés suivantes : le passage à l échelle, la tolérance aux pannes, la découverte des pairs, la quantité de messages échangés, la latence des transmissions et la non-imputabilité des actions Passage à l échelle Dans le cadre de l adaptation du réseau hôte, le support du passage à l échelle dépend de la croissance des besoins en ressources nécessaires pour le fonctionnement du système au niveau de chaque pair par rapport au nombre de pairs présents. Ainsi, cette capacité peut être évaluée en fonction du nombre de messages transmis par chaque pair, ainsi que la quantité de données devant être stockée afin de retrouver un pair sur le système. Les approches basées sur un serveur d adressage ne peuvent supporter le passage à l échelle du nombre de pairs présents dans le système, car elles centralisent l ensemble des données nécessaire aux communications des pairs au niveau d une seule machine aux ressources limitées. Ainsi, seules les approches basées sur les overlay peuvent supporter cette propriété [55]. De plus, toutes les approches basées sur les overlasy ne supportent pas toutes le passage à l échelle. En effet, le nombre de messages nécessaire pour retrouver un pair dans le système peut être très élevé si l overlay n est ni structuré ni hiérarchisé. Ainsi, les approches par inondation ne permettent pas le support d un nombre important de pairs 60

77 3.4. Couche d adaptation du réseau hôte dans le système, car elles nécessitent un nombre très important de retransmissions des messages [55]. De même, si le nombre moyen de retransmissions est plus faible dans le cas d une approche reposant sur les marches aléatoires, il reste très élevé surtout dans le cas de recherches de pairs complètes ou exactes. Ces deux mécanismes doivent donc être biaisés [40, 28] pour qu un overlay ni structuré ni hiérarchisé puisse supporter le passage à l échelle. En revanche, les overlay hiérarchisés permettent de supporter le passage à l échelle. En effet, la hiérarchisation permet de réduire fortement le diamètre d un overlay et de partiellement centraliser une partie des transmissions, ce qui réduit considérablement le nombre de messages nécessaire aux mécanismes d inondation et de marche aléatoire. De plus, les approches reposant sur une hiérarchisation dure sont plus performantes en termes de support du passage à l échelle, car elles permettent de cloisonner l utilisation de mécanismes aux seuls échanges entre les super-pairs. Ainsi, des mécanismes comme l inondation ne sont utilisés que dans un groupe restreint de pairs, ce qui permet au système de supporter le passage à l échelle [55]. Les overlay structurés permettant de router les messages entre les pairs jusqu à leur destination sont les approches qui supportent le mieux le passage à l échelle. En effet, chaque pair n entretient qu un nombre limité de liens avec d autres pairs du système, la transmission d un message entre n importe quel couple de pairs ne nécessite au plus que O(log 2 (n)) retransmissions, avec n le nombre de pairs présent dans le système [66, 92] Tolérance aux pannes De par leur nature fortement distribuée et décentralisée, les systèmes P2P peuvent supporter les pannes de plusieurs de leurs pairs sans compromettre le fonctionnement du système. Afin d être tolérant aux pannes, il faut que les informations nécessaires au fonctionnement du système soient suffisamment redondées entre les pairs du système. Ainsi, dans le cas d une approche centralisée, l ensemble des données nécessaire aux communications entre les pairs n est présent qu au niveau du serveur, ce qui empêche les systèmes basés sur cette approche de tolérer une panne du serveur. Les approches basées sur les overlay offrent une bonne tolérance aux pannes. En effet, chaque pair maintient les informations nécessaires pour contacter un certain nombre de pairs présent dans le système, même si certains pairs quittent le système, les communications entre les pairs seront toujours possibles. Ainsi, plus les pairs possèdent des informations sur un grand nombre d autres pairs présents dans le système, plus la tolérance aux pannes du système sera forte. En revanche, la hiérarchisation de l overlay peut limiter cette tolérance aux pannes en réduisant le nombre de pairs connus par les pairs les plus bas dans la hiérarchie [11]. De même, dans le cas particulier des overlay structurés, la tolérance aux pannes est principalement maintenue par les liens courts entre les pairs voisins sur l espace métrique. En effet, tant qu un pair reste lié à l ensemble de ses voisins, 61

78 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P les messages seront toujours garantis d atteindre leur destination [66]. Enfin, la fréquence de mises à jour des informations sur les pairs est aussi un facteur important pour la tolérance aux pannes du système. En effet, plus ses informations sont mises à jour régulièrement, plus il est facile pour un pair de compenser la perte d informations due au départ d un pair. Ainsi, plus les pairs échangent régulièrement des messages plus le système sera tolérant aux pannes Découverte des pairs La principale fonctionnalité de la couche d adaptation du réseau hôte est de permettre à un pair de trouver d autres pairs dans le système. Son principe est qu un pair envoie une requête définissant le ou les pairs qu il souhaite retrouver dans le système et la couche d adaptation du réseau hôte doit lui retourner l ensemble des informations lui permettant de communiquer avec ce ou ces pairs. On distingue deux approches définies dans le type de recherche que cette fonctionnalité peut autoriser : les recherches par propriétés et les recherches par identifiants Par propriétés Le principe de ce type de recherche est de permettre de retrouver un ou plusieurs pairs en fonction de leurs propriétés. En effet, il n est pas toujours nécessaire de pouvoir retrouver un pair précis dans un système P2P, mais uniquement un ou plusieurs pairs partageant certaines propriétés, par exemple que les pairs hébergent une ressource particulière. On peut distinguer les cas où le système doit pouvoir retrouver l ensemble des pairs partageant les propriétés définies dans la requête et les systèmes qui ne nécessite qu un certain nombre de pairs Complète Dans le cas d une recherche complète par propriétés, le système doit être capable de retourner les informations permettant de contacter l ensemble des pairs possédant les propriétés définies dans la requête. Les approches reposant sur un serveur d adressage sont les plus efficaces pour répondre à ce besoin. En effet, connaissant l ensemble des pairs présent dans le système, le serveur peut immédiatement retourner l ensemble des pairs répondant aux propriétés de la requête. En revanche, une telle approche n est possible que si les propriétés utilisées dans la requête ont été préalablement définies. En effet, il faut que le serveur possède les informations relatives à ces propriétés pour pouvoir traiter la requête. De même, les approches basées sur des overlay structurés et/ou hiérarchisés peuvent supporter ce type de recherches si les propriétés utilisées dans les requêtes ont été préalablement définies. En effet, la hiérarchie peut être organisée de sorte que l ensemble des pairs répondant à certains critères soit regroupé. Il est alors possible de diriger les requêtes 62

79 3.4. Couche d adaptation du réseau hôte vers le groupe de pairs possédant les propriétés désirées. De même, l espace métrique utilisées pour former un overlay structuré peut permettre de représenter les propriétés pouvant faire l objet de recherches. Ainsi, chaque dimension de l espace métrique correspond à une propriété et les coordonnés des pairs dans cette espace reflètent l adéquation de ces pairs avec les critères de recherche. Les pairs sont alors regroupés en fonction de leurs propriétés ce qui permet de diriger les requêtes vers la zone de l espace métrique correspondant aux propriétés désirées. Enfin, si il n est pas possible de définir préalablement les propriétés pouvant être utilisées dans les requêtes, la seule solution consiste à interroger l ensemble des pairs présents dans le système. Un overlay hiérarchique est alors la solution la plus adaptée pour répondre à ce besoin. De même, la structuration permet aussi d améliorer les performances de diffusion d une requête en réduisant le diamètre du graphe formé par les liens entre les pairs, par rapport à un overlay ni structuré ni hiérarchisé Partielle Certains systèmes n ont pas besoin de trouver les pairs répondant aux propriétés définies dans la requête, mais au moins un. Ce type de configuration impose beaucoup moins de contraintes que le cas précédent et permet donc plus de libertés pour la création du système. Contrairement au cas où le résultat doit être complet, les systèmes basés sur un serveur d adressage ne sont pas intéressants dans le cas de résultats partiels. En effet, l absence de complétude des résultats ne relaxe aucune des contraintes de ce type de système, comme le besoin de définir préalablement les propriétés considérées et le non-support du passage à l échelle ou de la tolérance aux pannes. Dans le cas des overlay, les contraintes associées aux approches basées sur la hiérarchisation ou la structuration pour regrouper les pairs en fonction de leurs propriétés ne bénéficient que très peu du fait que la contrainte de complétude soit relaxée. En effet, si cela permet de limiter le nombre de messages nécessaire pour répondre à une requête par rapport au cas où la réponse doit être complète, il est toujours nécessaire de définir préalablement les propriétés qui pourront être considérées. En revanche, il n est plus nécessaire de contacter l ensemble des pairs pour pouvoir répondre à ce type de requête. En effet, il suffit de contacter un nombre suffisant de pairs pour que la probabilité d en trouver au moins un répondant à la requête soit très élevée. Ainsi, si le système n a besoin que de résultats partiels, il est possible d utiliser n importe quel type d overlay sans pour autant compromettre la capacité de passage à l échelle du système. En revanche, une hiérarchisation des pairs permet toujours de limiter le nombre de retransmissions des requêtes, ainsi qu une structuration, mais dans une moindre mesure. En revanche, ce type d approche peut entrainer des erreurs de type faux négatif dans les résultats, quand une recherche porte sur des pairs possédants des propriétés très rares. Cependant, il est possible de quantifier la probabilité de faux négatifs si l on connait le nombre de pairs présents dans le système [99]. 63

80 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Par identifiant Ce type de recherche permet de retrouver un pair unique dans le système. Ainsi, pour un identifiant donné, le système retourne l ensemble des informations permettant de contacter ce pair ou le pair qui possède l identifiant le plus proche de celui demandé. Cette approche est donc utile quand les recherches portent sur un pair précis du système. Les overlay structurés et les approches reposant sur un serveur d adressage sont les plus adaptés à ce type de requête dans le sens où ils permettent d atteindre n importe lequel en un nombre de retransmissions très limité [66]. Pour n importe quelle autre approche, cela reviendrait a effectuer une recherche par propriété sur un seul critère dont le résultat doit être complet. Ainsi, il faut contacter l ensemble des pairs présents dans le système pour pouvoir répondre à la requête Quantité de messages transmis Un facteur important pour discriminer les approches d adaptation du réseau hôte est la quantité de messages nécessaires pour découvrir un pair dans le système. En effet, cette propriété permet de déterminer l impact qu à une approche sur le réseau hôte et donc le coût d une approche si l utilisation de ce réseau est payant. Les approches basées sur des overlays ni structurés ni hiérarchisés sont les plus mauvaises dans le domaine, car elles nécessitent l envoi d un très grand nombre de messages pour découvrir un pair dans le système, qu elles reposent sur un mécanisme d inondation ou de marche aléatoire. La hiérarchisation de l overlay permettant de réduire le diamètre de l overlay, il permet de réduire considérablement le nombre de messages nécessaire, mais ce nombre reste bien supérieur aux autres approches [55]. Les approches basées sur un serveur d adressage sont les plus efficaces, car elles ne nécessitent qu un seul échange avec le serveur pour fonctionner. Les overlays structurés sont un compromis entre ces approches, car elles permettent la découverte des pairs en un nombre limité de retransmissions par rapport aux overlays non structurés. La hiérarchisation d un overlay structuré permet de réduire encore plus son diamètre, ce qui diminue légèrement le nombre de messages nécessaires par rapport à une simple structuration Latence Avec le temps de calcul nécessaire au traitement, le temps nécessaire à la transmission des messages entre les pairs détermine la réactivité du système. Ainsi, le temps nécessaire à la transmission des données entre les pairs impacte fortement le temps nécessaire à la résolution des services. Cette latence peut avoir deux causes distinctes : le temps nécessaire pour retrouver un pair dans le système et le temps nécessaire à la transmission d un message. 64

81 3.4. Couche d adaptation du réseau hôte De la recherche Le temps nécessaire pour retrouver un pair dans le système peut varier fortement en fonction de l approche retenue. En effet, plus la taille de la chaine de retransmission nécessaire pour trouver le ou les pairs répondant à une requête sera longue, plus la latence due à la recherche sera grande. Les approches les plus efficaces pour limiter la latence due à la recherche de pairs dans le système sont l utilisation d un serveur d adressage ou d avoir un overlay où tous les pairs du système possèdent les informations nécessaires pour communiquer directement les uns avec les autres. En revanche, aucune de ses solutions ne permet au système de supporter le passage à l échelle en nombre de pairs. Dans les autres approches, celle basée sur l inondation de l overlay est efficace, car elle permet de retrouver les chaines de retransmission les plus courtes, mais elle nécessite l envoi d un très grand nombre de messages. Celle basée sur la marche aléatoire est la plus mauvaise, car la taille de la chaine de retransmission est dépendante du nombre de pairs dans le système. Une approche basée sur les overlays structurés représente un compromis entre les deux approches précédentes, car elle permet de trouver des chaines de retransmissions courtes sans nécessiter un grand nombre de messages. Enfin, quelle que soit l approche retenue, plus le nombre de pairs pouvant être contacté par un pair du système est grand, plus le diamètre de l overlay sera faible et donc plus les chaines de retransmissions seront courtes. Ainsi, le temps de latence dû à la recherche sur un overlay peut être réduit en augmentant le nombre d informations maintenues au niveau de chaque pair De la transmission Si la taille de la chaine de retransmission permettant de retrouver un pair dans le système impacte la latence, le temps nécessaire à chacune des transmissions de cette chaine est aussi impactant. Ainsi, plus les liens qui relient les pairs de l overlay sont décorrélés de la topologie du réseau hôte, plus le temps nécessaire à chacune des transmissions sera grand [69, 59]. Cette propriété touche exclusivement les systèmes basés sur des overlay où chaque pair ne connait pas l ensemble des autres pairs présents dans le système. En effet, dans les autres cas il n y a pas de retransmission de pair en pair. N ayant aucune contrainte sur le choix des pairs devant être connus par un pair, les overlays qui ne sont ni structurés, ni hiérarchisés sont les plus à même de suivre la topologie du réseau hôte [69]. En revanche, les pairs n ayant aucune information sur les pairs du système auxquels ils ne sont pas liés il est difficile d optimiser la topologie de l overlay. À l inverse, les overlay structurés ou hiérarchisés peuvent collecter plus d informations sur les pairs présents dans le système et donc plus facilement optimiser la topologie de l overlay. Ainsi, si l absence de structuration et de hiérarchisation permet une plus grande optimisation, elles la rendent aussi plus difficile à mettre en œuvre. 65

82 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P La non-imputabilité des actions Si l imputabilité des actions est définie comme un besoin de sécurité [5], l absence de cette imputabilité peut faciliter la liberté d expression dans des contextes particuliers [40, 129]. La nature distribuée des systèmes P2P peut permettre de garantir, au moins partiellement, la non-imputabilité des actions des utilisateurs dans le système. On peut distinguer deux propriétés qui permettent la non-imputabilité des actions, la capacité de répudiation et l obscurcissement du système Capacité de répudiation Pour garantir un niveau minimum de non-imputabilité, il faut que le système ne permette pas de déterminer quel pair est l initiateur d une requête. Il est alors possible pour n importe quel pair de répudier une de ses actions sur le système [2]. Les overlays possédant une hiérarchisation dure et les approches basées sur un serveur d adressage ne permettent pas d obtenir ce type de fonctionnalités. Dans le cas d une hiérarchisation dure, les pairs les plus bas dans la hiérarchie sont automatiquement identifiés par les pairs auxquels ils sont liés comme les initiateurs des messages qu ils transmettent. En effet, les pairs les plus bas dans la hiérarchie ne peuvent retransmettre de messages issus d autres pairs que d eux même. Il en va de même pour les approches basées sur un serveur d adressage où les pairs contactent directement le serveur sans retransmission des messages par d autres pairs. Les autres approches basées sur les overlay peuvent permettre la répudiation des actions des pairs dans le système si elles ne transmettent pas les informations sur l initiateur des requêtes. En revanche, dans le cas d overlay structurés, il faut aussi biaiser le mécanisme de routage afin qu il ne permette pas de retrouver l initiateur d une requête à partir de la longueur sur l espace métrique des liens utilisés pour former la chaine de retransmission. En effet, avec un algorithme glouton [92], les liens utilisés pour retransmettre les messages sont de plus en plus longs, plus on se rapproche de l initiateur de la requête [69] Obscurcissement L obscurcissement d un overlay consiste à masquer la présence d un pair dans le système à tous autres pairs que ceux auxquels il est lié. Ainsi, en limitant les liens avec les autres pairs qu à des pairs détenus par des utilisateurs de confiance, il est possible de créer un système qui garantisse la non-imputabilité des actions si aucun pair ne trahit [129, 78]. Ces systèmes étant basés sur la confiance entre les utilisateurs, une approche reposant sur un serveur d adressage n est envisageable que si l ensemble des pairs a confiance en le propriétaire du serveur. De même, dans le cas d un overlay avec une hiérarchie dure, il faut que les pairs liés à un pair supérieur dans la hiérarchie aient tous confiance en le possesseur de ce pair et les membres d un même niveau hiérarchique aient confiance les uns dans les autres. 66

83 3.4. Couche d adaptation du réseau hôte Les overlays non hiérarchisés et non structurées sont les plus adaptés pour répondre à ces besoins, car aucune supposition n est faite sur le choix des liens entre les pairs. Ce choix peut donc être guidé par la confiance entre les utilisateurs sans que cela ne nuise au système. De même, ce choix étant libre, il peut conduire à une hiérarchisation souple de l overlay, avec des pairs partageant plus de liens de confiances que d autres. Enfin, les liens entre les pairs reflétant des relations de confiance entre les utilisateurs et donc une organisation sociale, ils tendent à former un small-world [121, 176]. Il est donc possible de faire tendre l overlay formé vers un overlay structuré sans perdre les propriétés d obscurcissement de celui-ci [142, 52]. En revanche, les performances de routage d un tel overlay seront inférieures à celles d un overlay structuré Grille d analyse de la couche d adaptation du réseau hôte À partir de cette étude sur les propriétés relatives aux fonctionnalités de la couche d adaptation du réseau hôte, nous en déduisons le contenu des tableaux 3.5 et 3.6. On constate, dans le tableau 3.5, le très faible nombre d incompatibilités entre les propriétés pouvant être développées au niveau de cette couche. Cette particularité peut s expliquer par le tableau 3.6 qui montre que les overlays structurés sont une approche particulièrement polyvalente qui permet d implémenter au moins partiellement l ensemble des propriétés que nous avons défini. Ainsi, la structuration permet d améliorer les performances d un overlay dans presque toutes les situations en rendant cet overlay navigable ou simplement en réduisant le diamètre de son graphe. On peut aussi constater qu une approche basée sur un serveur d adressage représente un compromis particulier offrant de très bonnes performances pour la découverte des pairs. En revanche, leur incapacité à supporter le passage à l échelle et à tolérer les pannes réduit fortement les contextes dans lesquels ils peuvent être utilisés. 67

84 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P Passage à l échelle Tolérance aux pannes Découverte par propriétés complète Table 3.5 Incompatibilités des besoins et contraintes dégages pour la couche application Passage à l échelle NA Tolérance aux pannes NA Découverte par propriétés complète Partielle Incompatible Par identifiant Nombre de messages Latence de la recherche Latence de la transmission Capacité de répudiation Obscurcissement Partielle Par identifiant NA Obligatoire NA Incompatible Incompatible NA Nombre de messages NA Latence de la recherche NA Latence de la transmission NA NA Capacité de répudiation Obscurcissement NA 68

85 3.5. Interdépendance entre les approches Table 3.6 Types d approches associées aux besoins et contraintes dégages Serveur d adressagchisturturé Overlay simple Overlay hiérar- Overlay struc- Overlay struc- et hiérarchisé Passage à l échelle Tolérance aux pannes Découverte par propriétés complète Partielle Par identifiant Nombre de messages Latence de la recherche Latence de la transmission Capacité ++ + de répudiation Obscurcissement Interdépendance entre les approches Les systèmes P2P étant composés de l empilement de plusieurs fonctionnalités interagissant les unes avec les autres, il est nécessaire de prendre en compte les synergies possibles entre les approches utilisées au niveau de chaque couche dans notre analyse. En pratique, il est possible d utiliser n importe quelles combinaisons d approches pour 69

86 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P créer un système. En effet, chacune des approches définies dans l état de l art du chapitre précédent possède le minimum de fonctionnalités suffisantes pour répondre aux besoins des autres couches. En revanche, certaines combinaisons d approches semblent plus pertinentes que d autres. Ainsi, l utilisation d un overlay structuré permet de router les messages vers un pair précis et un index distribué regroupe les ressources en fonction de leurs critères. Contrairement aux analyses fonctionnelles de chacune des couches, l objectif de cette analyse n est pas de réduire le nombre d approches possibles, mais uniquement de départager différentes approches qui peuvent répondre à l ensemble des besoins. En effet, comme toutes les combinaisons d approches restent possibles, notre objectif avec cette analyse est d indiquer lesquelles sont les plus compatibles entre elles. Ainsi, cette analyse n indique en aucun cas des combinaisons à ne pas utiliser, mais seulement celles dont les propriétés sont les plus compatibles ou incompatibles entre-elles. Nous ne considérerons ici que deux types de synergies, celles entre la couche d adaptation du réseau hôte et la couche d indexation et celles entre la couche d adaptation du réseau hôte et la couche d application. En effet, il est possible de déterminer les synergies entre les couches d indexation et d application à partir de celles que nous présentons, en utilisant les résultats pour la couche d adaptation du réseau hôte comme pivot. Le choix d utiliser cette couche comme pivot vient du fait qu elle est celle qui a été la plus étudiée dans la littérature et le plus souvent utilisé comme base pour les états de l art précédents [55, 16, 45, 108, 80]. Table 3.7 Grille d analyse des synergies entre les approches de la couche indexation et adaptation du réseau hôte. Les cases vides correspondent à des relations neutres Serveur d adressage Overlay simple Overlay structuré Index global centralisé ++ Index global répliqué Index locaux Index partagés Index distribués sans sémantique Index distribué avec sémantique hié- Overlay rarchique structuré Les résultats du tableau 3.7 présentant les synergies entre les couches d indexation et d adaptation du réseau hôte recoupent en grande partie le tableau 2.1 des combinaisons 70 Overlay hiérarchique

87 3.5. Interdépendance entre les approches Table 3.8 Grille d analyse des synergies entre les approches de la couche d application et adaptation du réseau hôte. Les cases vides correspondent à des relations neutres Collecte de données Diffusion de données Délégation de traitement Traitement de flux Serveur d adressage Overlay simple Overlay structuré hié- Overlay rarchique structuré Overlay hiérarchique ayant données lieu à des systèmes existants. Parmi les différences notables, les combinaisons d approches proposées par BitTorrent [79] et PlanetP [42] ne représentent aucune synergies particulière. En effet, chacun de ces systèmes utilise un overlay non structuré pour assurer les communications entre les pairs. Or, si cette approche a le bénéfice de la simplicité, elle reste inférieure aux overlays structurés ou/et hiérarchisés dont les graphes formés possèdent des diamètres plus faibles [30]. À l inverse, plusieurs synergies indiquées dans le tableau 3.7 n ont pas donnés lieu au développement de systèmes dans l existant. En effet, ces synergies correspondent à des propriétés connues qui ont été utilisées, au moins partiellement exploitées dans d autres approches. Ainsi, la réduction du diamètre du graphe formé par les liens entre les pairs des approches hiérarchiques reste valable même avec l utilisation d un index local. De même, l approche utilisée dans SIMPEER [54] de combiner un index distribué avec sémantique conjointement à un overlay hiérarchique reste aussi valable pour un index distribué sans sémantique. Le tableau 3.8 présente les synergies entre la couche d adaptation du réseau hôte et la couche d application met en évidence plusieurs résultats. Le premier est que la collecte de donnée ne présente aucune synergie particulière. Ce résultat peut s expliquer par le fait que cette approche correspond au fonctionnement de base d un système P2P et qu elle est donc totalement prise en charge par l ensemble des systèmes qui peuvent être composés avec notre grille. Les synergies négatives entre les approches par serveur d adressage et la diffusion de données et le traitement de flux peuvent s expliquer par le fait que ces deux dernières ont été spécifiquement développées pour bénéficier du routage des messages sur un overlay. Enfin, les autres synergies correspondent, comme pour celles entre la couche d indexation et d adaptation du réseau hôte, à des combinaisons ayant données lieu à des systèmes existants, comme la délégation de traitement avec un serveur d adressage [14] ou sur un overlay hiérarchisé [146]. 71

88 Chapitre 3. Proposition d une grille d analyse pour l aide à la conception des systèmes P2P 3.6 Conclusion Dans ce chapitre, nous avons analysé les fonctionnalités et propriétés associées à chacune des couches fonctionnelles que nous avons définies dans notre état de l art du chapitre 2. Cette analyse nous a permis de déterminer l adéquation entre les approches pouvant être utilisées au niveau de chacune de ces couches avec les besoins et contraintes pouvant être associés au développement d un système P2P. Le résultat est regroupé en sept tableaux que nous utilisons pour former une grille d analyse permettant de déterminer quelle combinaison d approches est la plus adaptée à la création d un système P2P pour un contexte donné. Notre analyse a, de plus, permis de mettre en évidence certaines particularités dans le choix des approches à utiliser pour créer un système P2P. Ainsi, on peut constater que l utilisation d un overlay structuré est généralement une bonne approche quelque soit le système que l on souhaite créer. Ainsi, le choix d une approche relative à l adaptation du réseau hôte est finalement très peu impactante pour le développement du système, car un overlay structuré s avère toujours une solution efficace. À l inverse, toutes les approches relatives à la couche d indexation représentent un compromis particulier, aucune n étant efficace pour répondre à tous les besoins. Ainsi, la principale problématique dans le développement d un système P2P sera de choisir l approche la plus adéquate au niveau de la couche d indexation. D autant plus que ce choix permet de discriminer les approches les plus adaptées au niveau de la couche d adaptation du réseau hôte. À partir des sept tableaux que nous avons dégagés de notre étude sur les fonctionnalités et propriétés relatives aux différentes couches, il est possible d identifier quelle combinaison d approches est la plus adaptée pour composer un système P2P pour un contexte donné. Nous avons donc mis à l épreuve notre grille d analyse avec deux contextes applicatifs très différents que nous présentons dans le chapitre suivant. 72

89 CHAPITRE 4 DEUX ÉTUDES DE CAS POUR ÉVALUER NOTRE GRILLE D ANALYSE Dans ce chapitre nous présentons les deux contextes applicatifs pour lesquelles nous utiliserons notre grille d analyse pour proposer un système P2P adapté. Ces deux contextes sont les systèmes de fournisseur de services à l habitat et les archives scientifiques. Le choix de ces deux contextes applicatifs est principalement circonstanciel, dans le sens où ils correspondent à deux projets existants ayant participé au financement de la thèse. Ainsi, le contexte un système de fournisseur de services à l habitat correspond à un projet industriel alors que le contexte des archives scientifiques correspond à un projet de recherche financé par la région. Cependant, ces deux contextes ont été en partie choisis de sorte à être très différents l un de l autre de sorte à permettre l évaluation des capacités de notre grille d analyse. Ce chapitre est donc découpé en deux parties, chacune d elles étant dédiée à la présentation de ces deux contextes applicatifs. 4.1 Le cas d un système de fournisseur de services à l habitat Dans le cadre d un projet industriel, nous avons exploré la possibilité de créer un système de fournisseur de services à l habitat basé sur le modèle P2P. Afin d évaluer la pertinence de cette approche, nous avons étudié les différents domaines associés à la proposition de services à l habitat ainsi que les systèmes existants. Nous en avons déduit un modèle générique de système de fournisseur de services à l habitat qui nous servira de base pour élaborer un tel système en utilisant le modèle P2P. 73

90 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse Les systèmes de fournisseur de services à l habitat Le principe des services résidentiels est d installer chez les clients des objets communicants comme des capteurs et des actionneurs afin qu ils puissent, par exemple, contrôler leur habitat depuis Internet ou permettre de maîtriser la consommation d énergie d un habitat par le fournisseur pour équilibrer la charge globale du réseau électrique. Actuellement, les problématiques relatives à la mise en place de services au sein de l habitat sont principalement portées par deux domaines de recherche, les Home Area Networks qui correspondent au modèle générique d architecture de services au sein de l habitat et les Smart Grids qui possèdent une partie relative à la création de services de gestion de la consommation l électrique au sein de l habitat des clients. Ces deux types d architectures sont présentés dans les deux sections. Enfin, dans une troisième partie, nous présenterons les offres, actuellement disponibles en France, de services de gestion de l énergie pour l habitat Les services à l habitat L idée de pouvoir automatiser et superviser un habitat à l aide d un système informatique est actuellement portée par deux domaines de recherche : les Home Area Networks et les Smart Grids. Le premier s intéresse principalement à l infrastructure matérielle déployée au sein des habitats permettant l automatisation et la communication de celui-ci avec l extérieur. À l inverse, les Smart Grids exploitent une architecture simplifiée basée sur les Home Area Networks afin de pouvoir offrir des services de gestion de l énergie. Bien que similaires, ces deux approches ont conduit à des systèmes différents possédant chacune des spécificités qui leur sont propres Home Area Networks Les Home Area Networks ou HAN correspondent à des réseaux au sein des habitats de particuliers. Ces réseaux sont composés des différents équipements capables de communiquer à la fois entre eux, mais aussi avec Internet. Ces objets communicants peuvent être utilisés pour superviser l habitat de l utilisateur, créer des actions automatisées ou encore permettre à un fournisseur de service externe d interagir avec l habitat de l utilisateur. Les HAN étant centrés sur l habitat de l utilisateur, ils n intègrent pas les fournisseurs de services qui peuvent potentiellement utiliser cette architecture. Ces dernières années, plusieurs travaux ont porté sur ce sujet [158, 47, 136, 77, 137, 173, 106]. À partir des différentes descriptions faites des HAN dans ces travaux, il est possible de proposer un modèle général pour les HAN. Ce modèle est composé des quatre acteurs suivants : la passerelle résidentielle, les objets communicants, un réseau de communication et l utilisateur (Fig. 4.1). La passerelle résidentielle, aussi appelée Home Gateway ou Residential Gateway, est la passerelle qui permet de relier le HAN à Internet et ainsi autorise la communication 74

91 4.1. Le cas d un système de fournisseur de services à l habitat entre le HAN et des services distants. En fonction de la topologie du réseau du HAN et des services qui y sont implémentés, l importance de la passerelle résidentielle peut varier. Ainsi, la passerelle résidentielle peut aller d une simple passerelle de communication avec l Internet à un nœud central de coordination du HAN. La passerelle résidentielle peut alors avoir à gérer les communications entre les différents objets communicants du HAN [158] ou implémenter des fonctionnalités dédiées à des services souscrits auprès d un fournisseur de services [136, 137]. Les objets communicants correspondent à l ensemble des équipements de l habitat capables de communiquer à la fois à l intérieur du HAN. On distingue généralement deux principaux types d objets communicants : les capteurs, qui collectent des informations sur l habitat, et les actionneurs qui peuvent agir sur celui-ci. Pour communiquer, ces objets utilisent le réseau du HAN ainsi que la passerelle résidentielle pour échanger avec l extérieur via Internet. En fonction de leurs rôles dans le HAN, ces objets peuvent être fournis par un fournisseur de services afin qu il puisse interagir avec l habitat ou alors êtres installés directement par l utilisateur pour qu il crée ses propres fonctionnalités [137], comme l installation d un système de surveillance de l habitat 9 ou d un serveur de partage de contenu multimédia 10. Le réseau permet aux objets appartenant au HAN de communiquer les uns avec les autres. Les topologies et les technologies utilisées pour créer ces réseaux peuvent être très variées. Il est ainsi possible que ce réseau repose sur plusieurs de ces technologies en même temps. Ce réseau doit donc permettre, malgré l hétérogénéité des médias et protocoles de communication qui le compose de permettre aux objets du HAN de pouvoir échanger des informations, à la fois entre eux, mais aussi sur Internet. Figure 4.1 Modèle d architecture d un Home Area Network Des fournisseurs de services peuvent proposer aux utilisateurs des systèmes exploitant leur HAN. Ces fournisseurs peuvent soit exploiter les objets communicants déjà présents dans le HAN soit proposer des objets dédiés à leurs propres services pour que les utilisateurs les installent dans leurs HAN. Ils ne font donc pas partie du HAN, mais ne 9. http :// 10. http :// 75

92 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse font qu exploiter ce dernier [158]. Un HAN peut ainsi être relié à plusieurs fournisseurs de services en même temps, chacun d eux hébergeant leur propre système et pouvant proposer des interfaces de gestions de leur habitat à leurs clients. C est alors le système d information, ou SI, de ce dernier qui transférera les ordres de l utilisateur au HAN par l intermédiaire de son lien de communication avec la passerelle résidentielle. Enfin, L utilisateur est responsable de son habitat et donc des objets communicants qui le composent. C est lui qui installe et gère le HAN, même si dans certains cas, la passerelle résidentielle peut être cogéré avec le fournisseur d accès à Internet ou des fournisseurs de services [137]. L utilisateur communique avec le réseau d objets communicants présents dans le HAN pour superviser son habitat [47]. Cette communication s effectue généralement par l intermédiaire de la passerelle résidentielle, ce qui permet à l utilisateur d interagir avec le HAN depuis son habitat, mais aussi depuis Internet. Cette interaction depuis Internet peut alors se faire, soit en contactant directement la passerelle résidentielle ou en passant par une interface proposé par le fournisseur de services Smart grids Les smart grids sont devenus, ces dernières années, un enjeu majeur de nombreux états comme les USA 11, l Union Européenne 12 ou certains états asiatiques 13. Ces projets visent à intégrer de l intelligence dans les réseaux électriques actuels en allant du producteur électrique jusqu au consommateur [107, 162, 130]. Ainsi, dans le cadre de ces recherches, il a été envisagé de pouvoir interagir avec les habitats des clients pour optimiser leur consommation électrique [7] (Figure 2). Ces modèles d architectures visant à fournir des services au sein de l habitat du client sont généralement centrés sur un fournisseur particulier proposant uniquement des services de gestion de la consommation et la production d électricité. Ainsi, plusieurs grandes compagnies du secteur de la production électrique ou de la gestion de réseau de communication ont développé et commencent à exploiter leurs propres solutions comme Silverspring Networks 14, General Energy 15, PG&E [156], Southem California Edison [122], ou encore la société Echelon [110]. Ces architectures mises en œuvres pour fournir des services au sein de l habitat des clients sont assez similaires. Elles sont généralement composées d un réseau de capteurs/actionneurs, d une gateway ou passerelle, du compteur électrique qui joue un rôle particulier dans ces architectures, et d un SI distant (Fig. 4.2). Le réseau de capteurs/actionneurs est utilisé pour superviser l habitat des clients. Comme dans le cas des HAN, les capteurs collectent des informations sur l état de l habitat alors que les actionneurs sont utilisés pour agir sur celui-ci. En revanche, contrairement aux HAN, les technologies de communication utilisées pour les capteurs/actionneurs sont 11. IEEE Smart Grid, http ://smartgrid.ieee.org/, SSG SuperSmart Grid, http :// Asia Energy Platform, http ://aepfm.org/index.html, SilverSpring Networks, http :// Its your Smart Grid, http :// General Electric,

93 4.1. Le cas d un système de fournisseur de services à l habitat généralement limitées à une ou deux. En effet, cette architecture étant centrée sur la proposition aux clients de services liés à la gestion de la consommation électrique par un fournisseur de service, ce dernier peut imposer les technologies utilisables sur sa plateforme 16. Ce type d architecture utilise une gateway afin de permettre aux capteurs/actionneurs de communiquer avec le SI du fournisseur de services. Ainsi, la gateway communique à la fois avec le réseau de capteurs/actionneurs ainsi qu avec le SI distant généralement via Internet. Cette gateway peut à la fois être un équipement dédié imposé par le fournisseur de service ou un équipement déjà présent dans l habitat comme une passerelle résidentielle ou encore le compteur électrique. Le compteur électrique peut jouer plusieurs rôles dans ce type d architecture. De base, le compteur est considéré comme un capteur dans le sens où il permet de relever des informations agrégées sur la consommation électrique dans l habitat. En effet, la courbe de consommation électrique d un habitat est un agrégat de la consommation électrique de l ensemble des équipements présents dans cet habitat à un instant donné. De plus, dans certains cas, le compteur peut aussi servir de gateway permettant aux capteurs/actionneurs de communiquer avec le SI [7, 74]. Figure 4.2 Modèle d architecture de service au sein de l habitat dans les Smart Grids Enfin, ce type d architecture intègre un SI détenu par le fournisseur de service. Ce SI collecte et traite les informations enregistrées par les capteurs présents dans les habitats afin de fournir différents types de services. Ainsi, en fonction des informations collectées, le SI peut envoyer des ordres aux différents actionneurs présents dans l habitat afin, par exemple, de limiter la consommation électrique aux heures de pointe Différentes instanciations actuellement commercialisées en France À l heure actuelle, en France, plusieurs offres de services de gestion de l énergie sont présentes sur le marché ou en passe de le devenir. Cette section vise à faire un tour d horizon de ces différentes offres et principalement sur les architectures qu elles exploitent 16. EcoBee, http ://

94 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse et les services qu elles proposent aux clients. Actuellement, il existe six acteurs : Voltalis 17, Poweo 18, EcoBee 19, Wirecom 20, Ijenko 21 et Edelia 22. Le tableau 4.1 présente les principales caractéristiques de chacun d entre eux. Nous les détaillons ci-après. Voltalis propose des services de gestion de l énergie basée sur une box directement reliée au tableau électrique de l habitat. La box, appelée «BluePod», effectue des relevés sur la consommation électrique de l habitat et peut agir sur les appareils électriques comme le système de chauffage ou les ballons d eau chaude. Cette box communique avec le SI de Voltalis via le réseau mobile (GPRS, UMTS) pour remonter des informations ou recevoir des ordres. Deux services sont proposés gratuitement aux clients, le suivi de la consommation électrique sur Internet et la régulation automatique de cette consommation. Le premier consiste à proposer au client une interface web sur laquelle il peut consulter en temps réel l évolution de la consommation électrique de son habitat. Le deuxième consiste à gérer la consommation électrique de l habitat afin d aider le gestionnaire du réseau électrique français, RTE, à équilibrer le réseau électrique. En pratique, cela revient, pour Voltalis, à couper certains équipements électriques des clients comme le chauffage ou le ballon d eau chaude, en cas de pic de consommation et ainsi aider à maintenir l équilibre du réseau électrique. Pour ses clients, Voltalis promet que son système permet de diminuer de 5 à 12% leur consommation électrique et ainsi de faire des économies. Poweo, un commercialisateur/producteur d électricité concurrent à EDF, propose lui aussi un service gestion de la consommation électrique de l habitat. Ainsi, en 2008, Poweo proposait l installation d une «Poweo box» qui permet le suivi de la consommation électrique de l habitat du client. En pratique, cette Poweo box se compose de 3 modules. Le premier module, connecté au compteur électrique, permet d effectuer des relevés de consommation périodique. Le second, connecté à une ligne téléphonique ou à un modem ADSL présent chez le client, permet à la Poweo Box de communiquer avec le SI de Poweo. Le dernier module permet de visualiser en temps réel la consommation électrique de l habitat. En plus du module de visualisation de la Poweo Box, il est possible de suivre la consommation électrique de son habitat via le site web de Poweo. De nouveaux services ont été annoncés afin de compléter cette offre, dont des services de domotique, mais ils ne sont pas disponibles pour le moment. EcoBee est une solution de gestion de la consommation électrique de l habitat basée sur un thermostat intelligent. Le thermostat EcoBee est connecté à divers équipements de l habitat comme des radiateurs électriques, des ventilateurs, des humidificateurs d air ou encore des climatisations, et ce, à l aide de capteurs/actionneurs fournis avec le thermostat. Ainsi, le thermostat peut contrôler ces équipements de sorte à suivre la configuration 17. Voltalis, http :// Poweo, http :// EcoBee, http :// Wirecom Technologies, http :// Ijenko, http :// Edelia, http ://

95 4.1. Le cas d un système de fournisseur de services à l habitat choisie par le client. En plus de ce service local, le thermostat peut se connecter au SI d EcoBee afin de permettre au client d avoir accès aux données relevées sur son habitat et de modifier la configuration de son thermostat. Wirecom, de son côté, propose d exploiter un réseau de capteurs/actionneurs intelligents pour contrôler son habitat. Sa solution repose sur des modules autonomes connectés aux équipements électriques de l habitat qui s auto-organisent en réseau via un réseau CPL. En plus de ces capteurs/actionneurs, la solution Wirecom est complétée par des panneaux de contrôles et un boîtier appelé «S.P.L.I.» connectés aux réseaux CPL de capteurs/actionneurs. Les premiers offrent une interface de contrôle des différents modules présents dans l habitat. Le deuxième sert de passerelle afin que le réseau de capteurs/actionneurs puisse communiquer avec une interface de supervision. Le boîtier S.P.L.I. peut être connecté à un ordinateur ou alors directement à un modem/routeur ADSL afin qu il devienne accessible depuis Internet. Contrairement aux solutions présentées précédemment, le système Wirecom ne repose pas sur un SI distant, mais uniquement sur un logiciel de supervision de l habitat vendu au client. Ce logiciel se connecte au S.P.L.I. et permet de configurer le comportement des différents capteurs/actionneurs présents chez le client. La solution Ijenko, sponsorisée par Direct Energie et Bouygue Telecom, propose elle aussi de gérer son habitat à l aide d un réseau de capteurs/actionneurs semblable à celui de Wirecom. Ce réseau est complété par un capteur relié au compteur électrique et par une box. Cette dernière est connectée au modem ADSL du client afin de permettre la communication entre les équipements présents dans l habitat et le SI d Ijenko. Ce SI collecte les informations sur l habitat du client et lui offre une interface de gestion pour ses équipements reliés aux modules qu il a installés dans son habitat. Enfin, Edelia est la filiale d EDF chargée de proposer des solutions de services à l habitat. Son architecture dans l habitat repose sur trois capteurs installés respectivement sur le compteur d électrique, le compteur d eau et le compteur de gaz ainsi que d une box, appelé E-Box, qui relie le système à Internet. Cette box peut utiliser la connexion ADSL du client ou ouvrir sa propre connexion en GPRS. Les capteurs collectes les informations sur l habitat du client et les transmettent aux des centres de calculs d Edelia par l intermédiaire de l E-Box. Le principal service proposé aux clients est la visualisation en temps réel de sa consommation d eau, de gaz et d électricité ainsi que des alertes SMS. Ces services peuvent être augmentés par l ajout d autres capteurs/actionneurs pour la gestion à distance du chauffage ou un système d alerte médicale. 79

96 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse Table 4.1 récapitulatif des offres de services de gestion de l énergie au sein de l habitat en France Module à installer Interface de supervisiocation Medium de communi- Services proposés aux avec l extérieur clients Voltalis BluePod sur le tableau La BlueBox Réseau mobile (GPRS, Visualisation de la électrique UMTS) consommation électrique de l habitat, gestion automatique de la consommation électrique Poweo Un module sur le Un module de visualisation Réseau RTC et Visualisation de la compteur et un module et un site web connexion ADSL du consommation électrique de communication client de l habitat EcoBee Un thermostat communicant Le thermostat et un Connexion ADSL du Gestion par l utilisation et des cap- teurs/actionneurs site web client des équipements reliés au système Wirecom Des capteurs/actionneurs, Un logiciel de supervi- Connexion ADSL du Gestion par l utilisation un sion installé sur l ordi- client des équipements reliés au boitier S.P.L.I. pour la nateur du client système communication Ijenko Des capteurs/actionneurs, un module de communication Edelia Un boitier (E-Box), des capteurs pour les compteurs électrique, d eau et de gaz, des équipement pour contrôler le chauffage, système d alerte Un site web Connexion ADSL du client Site web et alerte par ou SMS Connexion ADSL du client Gestion par l utilisation des équipements reliés au système Visualisation de la consommation d électricité, d eau et de gaz, gestion du chauffage, système d alerte médicale 80

97 4.1. Le cas d un système de fournisseur de services à l habitat Proposition d un modèle générique d un système de fournisseur de services à l habitat L objectif de ce modèle générique d architecture est de fournir une base abstraite sur laquelle appuyer nos réflexions sur les architectures de fournisseur de services au sein de l habitat. Ainsi, ce modèle a pour but d être le plus générique possible. Il correspond donc à une abstraction de haut niveau de ce type d architecture. De ce fait, il est donc totalement indépendant des contraintes matérielles ou d une implémentation particulière. De plus, ce modèle est basé sur le cas d un fournisseur de services au sein de l habitat. Ainsi, il est centré sur un système distant permettant de fournir un nombre varié de services aux habitats des clients. Ce modèle vise à associer les travaux sur les services à l habitats précédemment proposés dans les domaines des HAN et des Smart Grids afin de présenter ces travaux du point de vu d un fournisseur de services à l habitat. En effet, les modèles basés sur la HAN sont centrés sur les habitats des clients, ils ne prennent donc pas en compte l architecture du fournisseur de services, mais seulement ce qu il en découle pour l habitat des clients. De même, les Smart Grids sont centrées sur des offres de services liées à l industrie de l énergie et limite leur architecture de services au sein de l habitat au compteur électrique des clients, même si la présence d autres services sont parfois évoqués [156, 122, 110, 23]. Ce modèle (Fig. 4.3) s inspire des différentes architectures existantes présentées dans le chapitre précédent en les replaçant dans le cadre d un fournisseur de services au sein de l habitat des clients. Il est composé de trois principales entités : le fournisseur de services, les sites et les utilisateurs. Figure 4.3 Modèle conceptuel d architecture de fournisseur de services au sein de l habitat 81

98 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse Le fournisseur de services Le fournisseur de services est défini comme une entité distante proposant un certain nombre de services pour les sites aux utilisateurs. À l heure actuelle, l architecture qui serait utilisée par le fournisseur de services reposerait sur un modèle de type SOA [88]. En effet, de nombreuses compagnies font migrer leur architecture de système d information vers ce modèle qui permet de représenter la multiplicité des services que ces systèmes peuvent proposer [9]. De plus, il répond aux besoins d évolution que peuvent avoir un fournisseur de services, dont l offre est susceptible d évoluer au cours du temps, de par ses propriétés comme le couplage lâche, interopérabilité et évolutivité via le découpage adéquat et la standardisation des services. En pratique, une architecture de type SOA peut se décomposer en deux types d acteurs, un bus et des services. C est cette décomposition que nous allons utiliser pour notre fournisseur de services (Fig. 4.4). Le rôle du bus est de servir de plateforme d échange entre les services, les sites et les utilisateurs. Dans ce modèle, le bus est un acteur passif dans le sens où il n effectue aucun traitement sur les informations qu il fait transiter. En revanche, il peut avoir à effectuer des traitements sur les messages eux-mêmes, comme de l ingénierie de trafic ou de la gestion de la sécurité des transmissions, afin pouvoir répondre aux besoins de qualité de services du système. Les services sont des briques fonctionnelles qui composent les applications hébergées au niveau de centre de traitements. C est l association de plusieurs de ces services qui permet la réalisation des services destinés aux utilisateurs finaux. Ainsi, chacun de ces services qui seront proposés aux clients pourra être composé d un ou plusieurs autres services.pour se coordonner, ces différents services communiquent entre eux au travers du bus. En plus des services situés chez le fournisseur, ce dernier peut aussi déporter certains traitements au niveau des sites comme on peut le voir dans certaines architectures de HAN [136, 137]. Ces services déportés communiquent avec les autres services pour former les services destinés aux utilisateurs finaux en passant par la gateway du site pour atteindre le bus. Figure 4.4 Représentation du fournisseur de services dans le modèle conceptuel 82

99 4.1. Le cas d un système de fournisseur de services à l habitat Les sites Les sites correspondent aux lieux pour lesquels sont fournis les services. Ce modèle conceptuel visant à être le plus générique possible, la notion de site est préférée à celle d habitat de l utilisateur du fait qu elle implique moins de présupposés. Un site est donc défini comme étant n importe quel lieu où sont installés les équipements nécessaires pour l exécution des services souscrits auprès du fournisseur de services. Enfin, un site se décompose en quatre acteurs, les capteurs, les actionneurs, des services déportés et une gateway. Cette décomposition correspond à ce que l on retrouve dans chacun des modèles vus précédemment, à l exception du compteur électrique et des services déportés. En effet, le rôle du compteur électrique dans les smart grids peut ici être décomposé par ceux d une gateway et d un capteur/actionneur. De même, les services déportés sont ici explicités afin de mieux représenter la présence du fournisseur de services au sein de l habitat des clients (Fig. 4.5). En effet, ce dernier point permet d offrir une représentation générique des différentes méthodes utilisées par les fournisseurs de services pour déporter des traitements dans les sites comme l installation d équipements dédiés ou la prise en charge de traitements par gateway [136, 77, 137]. Les capteurs et les actionneurs sont installés afin de permettre la mise en place des services proposés par le fournisseur de services ainsi que la supervision du site. Les capteurs servent à collecter des informations sur l état du site alors que les actionneurs ont pour rôle d agir sur cet état. Ces capteurs/actionneurs peuvent communiquer les uns avec les autres ainsi qu avec le fournisseur de services. Ce modèle étant centré sur le fournisseur de services, on considère que le ou les réseaux utilisés pour permettre aux capteurs/actionneurs de communiquer au sein du site sont normalisés comment dans le cas des Smart Grids. Ainsi, seuls les équipements correspondant à cette norme sont susceptibles de faire partie d un site et donc d être exploités par le fournisseur de services. Figure 4.5 représentation d un site dans le modèle conceptuel Un service déporté est un traitement que le fournisseur de service a placé au ni- 83

100 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse veau du site. Ces services peuvent être autonomes ou fonctionner en coopération avec des services hébergés par le fournisseur. Pour communiquer avec la structure du fournisseur, ces services déportés utilisent la gateway. À l image de capteurs/actionneurs, les services déportés utilisent la gateway pour communiquer avec la structure du fournisseur de service. Ils doivent donc obligatoirement pouvoir communiquer avec la gateway et donc respecter les mêmes contraintes que les capteurs/actionneurs sur les normes de communication au sein des sites. En revanche, les services déportés ne sont pas pour la responsabilité de l utilisateur, mais du fournisseur de services. Ainsi, leurs modifications sont strictement limitées au fournisseur. Enfin, les services déportés peuvent être associés à des capteurs/actionneurs dédiés à ce service. La gateway est semblable à celle des modèles précédemment cités. Son rôle se limite à servir de passerelle pour que les capteurs/actionneurs puissent communiquer avec le fournisseur de services. Ainsi, la gateway communique avec les capteurs pour collecter les informations relevées sur le site afin de les transférer au fournisseur de services. De même, elle sert aussi à transférer les ordres émis par le fournisseur de services vers les actionneurs Le client Les utilisateurs sont les propriétaires des sites qui ont souscrit aux offres proposées par le fournisseur de services. Contrairement aux deux entités précédentes, l utilisateur ne se compose pas en plusieurs acteurs. En revanche, il entretient de nombreuses interactions avec les sites et le fournisseur de services (Fig. 4.7). En tant que gestionnaire du site pour lequel il a souscrit des services auprès d un fournisseur, l utilisateur est le propriétaire des différents acteurs de ce site à l exception des services déportés et éventuellement de la gateway qui appartiennent au fournisseur de services. Ainsi, c est l utilisateur qui a la charge d installer et de configurer les capteurs/actionneurs et la gateway présents sur son site. Il peut donc communiquer avec l ensemble des acteurs du site par l intermédiaire du réseau local présent sur le site ou directement via une interface prévus sur le matériel comme des écrans tactiles ou de simples boutons associés à un afficheur. De même, c est l utilisateur qui a souscrit aux services proposés par le fournisseur de services. De ce fait, il est le principal destinataire des interfaces de gestion de services proposés par le fournisseur de services. Cette interface de gestion est généralement présentée sous la forme d un site web relié au bus du fournisseur de services Conclusion sur l étude du cas d un fournisseur de services à l habitat À l heure actuelle, il n existe pas vraiment de contexte précis relatif à un fournisseur de services à l habitat. En effet, dans le domaine des HAN, un fournisseur de services à 84

101 4.2. Le cas des archives scientifiques Figure 4.6 représentation des interactions de l utilisateurs avec les différents acteurs du modèle l habitat est représenté comme une entité extérieure capable d exploiter les équipements reliés à un HAN. De même, les Smart Grids présentent une vision limitée au relevé d informations sur les habitats des clients, n évoquant la possibilité de proposer des services à ces clients que comme une opportunité. Il n est donc pas surprenant qu aucune architecture servant à soutenir l activité d un fournisseur de services à l habitat n ait été jusqu à présent proposée. Pour remédier à ce manque, nous avons donc proposé un modèle générique de système de fournisseur de services à l habitat basé sur les informations existantes dans le domaine des HAN et des Smart Grids sur lequel nous pourrons nous appuyer pour élaborer notre système. L utilisation du modèle P2P pour l élaboration d un tel système est intéressante, dans le sens où plusieurs besoins associés à un fournisseur de services à l habitat peuvent être pris en charge par ce type de modèle. En effet, des propriétés comme la tolérance aux pannes ou la capacité à supporter le passage à l échelle en nombre de clients et de services sont particulièrement importantes pour ce type d acteur. Or le modèle P2P possède de bien meilleures performances sur ces deux propriétés que le modèle Clients/Serveur. 4.2 Le cas des archives scientifiques Les travaux sur les archives scientifiques rentrent dans le cadre d un projet régional visant à développer un outil permettant l archivage des documents de travail des chercheurs et plus particulièrement des documents numériques. Dans un premier temps, nous présenterons donc les archives scientifiques ainsi que les principes de l archivage appliqués aux documents numériques. Nous présenterons ensuite la théorie des trois âges qui définit les différents états d archivage dans lequel peut passer un document. Enfin, nous étudions le cas particulier du cahier de laboratoire numérique qui représente les documents de travail numériques des chercheurs. 85

102 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse Les archives scientifiques L archivage des documents numériques est une problématique d importance croissante. En effet, depuis le développement de l informatique grand public, la quantité de documents numériques ne cesse de croitre. Or la conservation de ces documents s est avérée difficile à cause de l évolution rapide des technologies. Ainsi, l obsolescence des supports de stockage ou les pertes de rétro compatibilité des logiciels de lecture rendent une quantité importante de documents numériques inutilisables 23. La production de documents scientifiques est particulièrement touchée par ce phénomène. En effet, une grande partie des documents produits n existe plus aujourd hui que sous forme numérique, surtout si l on prend en considération les documents au sens large. En effet, la production scientifique ne se limite pas aux seuls articles publiés, mais aussi aux résultats d expériences et tout autre document de travail. Si les cahiers de laboratoire des chercheurs permettaient de garder des traces de ces documents de travail [167], le passage aux documents numériques le fait petit à petit disparaitre des laboratoires de recherche. Ainsi, il devient nécessaire de développer des solutions afin de créer un équivalent numérique au cahier de laboratoire qui répondent aux besoins d archivage Objectifs de l archivage Traditionnellement, le domaine des archives est soumis à deux contraintes contradictoires. En effet, la première contrainte est de conserver et préserver les documents pour garantir leur accès futur. Or l accès aux documents est généralement la première source de détérioration de ces derniers. Ainsi, les techniques développées pour répondre à ces deux besoins entrent souvent en contradictions les unes avec les autres. Cette dualité se retrouve dans l archivage des documents numériques. Elle est même d autant plus importante que l accès aux documents est nécessaire afin de déterminer s il peut encore être lu Conservation des documents numériques Contrairement aux documents physiques pour lesquels il suffit de garantir l intégrité du document pour qu il puisse être lu, les documents numériques nécessitent aussi de préserver les programmes permettant d interpréter les données. En effet, un document numérique ne se limite pas aux données qui le composent, mais aussi aux programmes capables de les interpréter et donc de les rendre lisibles pour un être humain [118]. Ainsi, la conservation des documents numériques doit faire face à deux enjeux que sont la conservation des données et la conservation de leur moyens de lecture. 23. Digital Preservation Management : Implementing Short-Term Strategies for Long-Term Solutions, online tutorial developed for the Digital Preservation Management workshop, developed and maintained by Cornell University Library, ; extended and maintained by ICPSR, 2007-on. 86

103 4.2. Le cas des archives scientifiques De nombreuses méthodes existent pour évaluer l intégrité des données numériques, comme les certificats numériques et les empreintes de hachage [3]. De même, pouvoir faire des copies identiques de données numériques permet d assurer leur pérennité par une forte réplication sur différents supports et lieux de stockage. Ainsi, par une politique de management des données numériques, il est possible de garantir dans le temps l intégrité des données numériques, malgré les risques d obsolescence des moyens de stockage. En revanche, garantir l intégrité des données n est pas suffisant pour garantir la lisibilité d un document numérique, il faut aussi conserver les moyens de lecture de ces documents. En effet, l évolution rapide des formats numériques et des logiciels peut rapidement conduire à l impossibilité de lire un document numérique même si l intégrité des données qui le composent a bien été conservée. De plus, contrairement à l obsolescence des supports de stockage, l évolution des logiciels est devenue plus rapide et surtout moins prévisible. Ainsi, les changements de formats de fichier ou d algorithmes de lecture peuvent fortement affecter le rendu et donc l intégrité des documents numériques. Parmi les solutions envisagées, on distingue deux approches. La première consiste à utiliser un format de fichier dont la pérennité est garantie comme le standard PDF/A [48]. Une autre approche proposée dans [118] consiste à conserver, au même titre que les documents, les environnements de lecture afin de pouvoir reproduire les mêmes conditions qu au moment de la rédaction du document. Basée sur la virtualisation des environnements de travail, cette approche a l avantage d être réflexive et donc de s appliquer à elle-même. Ainsi, l environnement permettant de lire une machine virtuelle peut aussi être virtualisé afin de pouvoir être lui-même archivé. Cela assure donc une pérennité potentiellement illimité à cette approche Accessibilité des documents numériques L accès à des documents a pendant longtemps été contradictoire avec sa conservation, le support physique classique ne pouvant être préservé que dans des conditions particulières et peu adaptées à leur lecture. En revanche, les documents numériques ne souffrent pas de cette limitation, ces derniers pouvant très facilement être copiés à l identique, la génération de copie spécialement dédiée à leur lecture est tout à fait réalisable. Pourtant les systèmes permettant de rechercher et d accéder aux documents numériques sont généralement dissociés de ceux visant à les conserver de façon sûre et pérenne. La gestion électronique des documents, ou GED, correspond à des systèmes dont le but est de gérer des bibliothèques de documents qui peuvent être aussi bien numériques que physiques [83]. Ces systèmes décrivent les documents qu ils gèrent de sorte à fournir aux utilisateurs des fonctionnalités de recherche avancées. Cette description est gérée par l attribution de mots-clefs qui peut être effectuée par le système lui-même [178] ou guidée par un schéma, comme Dublin Core [96]. Pour stocker les descriptions des documents ou les documents numériques, ces systèmes utilisent généralement des bases de données [94]. Or, ces systèmes n apportent généralement aucune garantie quant à la préservation des 87

104 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse données numériques qui y sont stockées. Ainsi, la préservation dans les GED n est vue que par la réplication des données, comme avec un système RAID [126]. Les systèmes existants ne privilégient généralement qu un seul des deux aspects de l archivage. Or ces deux aspects doivent être considérés afin de pouvoir proposer des archives numériques vraiment adaptées Théorie des trois âges Dans le domaine de la gestion des archives, on distingue trois différentes étapes dans le cycle de vie d un document. Cette théorie, communément appelé la théorie des trois âges [128], correspond aux différentes étapes qui régissent la vie d un document susceptible d être archivé. Ainsi, on distingue trois étapes dans la vie d un document : les archives courantes, semi-courantes et définitives Les archives courantes Cette première étape, appelée archive courante, correspond aux documents en cours de rédaction qui peuvent encore être modifiés. Les archives courantes sont donc caractérisées par un accès régulier aux documents ainsi que la possibilité de les faire évoluer. Le principal enjeu d une archive courante est de garder des traces des différentes révisions d un document. En effet, une archive courante doit permettre de suivre l évolution d un document et d accéder au contenu des différentes étapes de sa rédaction. Comme dans toute archive, les documents d une archive courante ainsi que l ensemble des révisions qui y ont été appliquées doivent être conservés de sorte à préserver leur intégrité. La durée de conservation d un document dans une archive dépend généralement des situations. En effet, les différentes révisions d un document sont généralement détruites quand ce dernier atteint sa version finale. Les révisions suivantes du document étant ensuite créées à partir de cette version de référence. L archivage des versions finales se fait principalement dans une archive semi-courante ou au niveau d une archive définitive Les archives semi-courantes L objectif de ce type d archive est de préserver des documents de référence pendant une durée plus ou moins longue. Contrairement aux documents d une archive courante, ceux d une archive semi-courante ne sont pas modifiables, car ils ont pour but servir de référence. De même, la propriété des documents stockés dans une archive semi-courante est plus complexe que pour les archives courantes. En effet, dans une archive courante, le propriétaire du document sont le ou les auteurs de celui-ci. En revanche, dans une archive semi-courante, la charge de la conservation des documents repose principalement sur des institutions qui peuvent être propriétaires des documents au même titre que les 88

105 4.2. Le cas des archives scientifiques auteurs eux-mêmes. C est par exemple le cas pour les documents relatifs à la propriété intellectuelle. La durée d archivage d un document dans une archive semi-courante dépend de la nature du document et du contexte. En effet, les documents stockés dans une archive semi-courante doivent pouvoir servir de preuve légale pendant toute leur durée d utilité administrative. Ainsi, les enjeux de ce type d archive sont de garantir l intégrité, la lisibilité et l accessibilité des documents qui y sont stockés pendant toute leur durée d utilité administrative Les archives définitives Comme leur nom l indique, les archives définitives visent à conserver de façon perpétuelle les documents qui y sont stockés. Elles répondent aux besoins de mémoire et sont principalement utilisées à des fins historiques. Ainsi, l ensemble des informations existant sur un sujet jugé d intérêt historique est regroupé dans une archive définitive, que ces informations proviennent d archives courantes ou semi-courantes. De même, la capacité d accès et de lecture des documents qui y sont stockés doit pouvoir être garantie pour une période potentiellement infinie. Ainsi, les enjeux de ce type d archive sont de garantir l intégrité, la lisibilité et l accessibilité des documents qui y sont stockés à très long terme Le cahier de laboratoire numérique Le cahier de laboratoire est à la fois à une archive courante et semi-courante 24. En effet, un cahier de laboratoire est un outil d aide à la mémoire des chercheurs qui peut potentiellement servir de preuve légale dans le cade de litiges sur la propriété intellectuelle d une découverte. Ainsi, chaque page du cahier doit être datée et signée par plusieurs personnes afin d attester de son contenu. Une très grande partie des documents produits aujourd hui par les chercheurs sont au format numérique ce qui rend la version papier du cahier de laboratoire obsolète. Ainsi, il est nécessaire de repenser une version numérique de ce type d outil indispensable pour protéger légalement les travaux des chercheurs. On distingue alors deux propriétés essentielles que le cahier de laboratoire numérique doit reproduire : l archivage des documents numériques et l outil de travail pour les chercheurs Archivage des documents numériques En tant que support à la mémoire du chercheur, le cahier de laboratoire numérique doit reproduire les fonctionnalités d une archive courante pour les documents numériques 24. CNRS : Petit guide pour la gestion du cahier de laboratoire national ; mpr/pratique/guides/cln/cln_guide-gestion.pdf 89

106 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse des utilisateurs. De même, son utilisation en tant que preuve légale fait qu il doit aussi supporter les contraintes d une archive semi-courante. Enfin, certains travaux pouvant se révéler d intérêt historique, il doit aussi pouvoir être transféré dans une archive définitive. En tant qu archive courante, les documents numériques formant le cahier de laboratoire numérique doivent pouvoir être modifiés. La traçabilité et l intégrité de chaque modification appliquée à un document du cahier doivent être garanties afin de ne pas compromettre l utilisation de ce document en tant que preuve légale. En effet, en cumulant les fonctions d archive courante et semi-courante, chaque révision d un document doit répondre aux contraintes des archives semi-courantes. Ainsi, le cahier de laboratoire doit au minimum garantir l intégrité, la lisibilité et l accessibilité de l ensemble des révisions appliquées à l ensemble des documents qui le composent pendant toute leur durée d utilité administrative. De même, les moyens de lecture de chacun de ces documents doivent être conservés de sorte à étendre la durée de préservation de chaque document du cahier de laboratoire afin de répondre aux besoins des archives définitives Outil de travail pour les chercheurs En plus d être une archive complexe, le cahier de laboratoire numérique est aussi un outil de travail pour les chercheurs. En effet, de par ses contraintes en tant qu archive, un cahier de laboratoire numérique est aussi un outil permettant de classer et d organiser les documents produits par l utilisateur, ainsi qu un système de gestion de révision. En plus de ces outils qui reflètent directement la nature des archives qui composent un cahier de laboratoire, le passage aux documents numériques apporte de nouvelles possibilités. En effet, l utilisation d un même schéma pour l organisation des documents dans les cahiers de laboratoire d une communauté permet de faciliter les échanges et donc de mutualiser les connaissances. Ainsi, il peut servir de support au partage de documents numériques, à l écriture collaborative de documents ainsi qu à la mutualisation de références bibliographiques Les cahiers de laboratoire actuellement disponibles Le marché des cahiers de laboratoire électroniques est plutôt mature avec actuellement plus d une trentaine de solutions commercialisées [138]. La plupart de ces solutions sont centrées sur des domaines d application précis comme la biologie, la chimie ou le contrôle qualité. Ainsi, de nombreuses fonctionnalités de ces outils n ont été développées que pour répondre aux besoins spécifiques de leur domaine d application, comme le support de la norme 21-CFR-Part11 25 pour les productions de documents dans le domaine médical. L ensemble de ces systèmes fonctionne sur les mêmes principes : CFR-Part11.com :

107 une solution tout-en-un : traitement de texte, gestion de documents, archivage, recherche documentaire ; une architecture centralisée : collecte de l ensemble des données au niveau d un serveur, collaboration entre les utilisateurs via le serveur, modèle de curation pour la préservation des données, recherche documentaire ; 4.2. Le cas des archives scientifiques De par leur nature centralisée, ces systèmes sont destinés à des institutions qui souhaiteraient déployer un cahier de laboratoire numérique pour mieux gérer la production de documents scientifiques de ses membres/employés. En effet, la centralisation des documents au niveau d un serveur implique que l entité propriétaire de ce serveur soit considéré comme digne de confiance par l ensemble des utilisateurs. De même, cet archivage centralisé pose le problème de la tolérance aux pannes dans le sens où le serveur est un point unique de rupture pour le système. Une autre limite de ces cahiers de laboratoire numériques est qu ils changent les méthodes de travail des utilisateurs en leur imposant de nouveaux outils. En effet, en imposant que la composition et la rédaction des documents soient effectuées au niveau l application du cahier de laboratoire, ces systèmes obligent les utilisateurs à abandonner leurs outils et leurs pratiques. Cela peut fortement limiter l adoption d un tel outil Conclusion sur l étude du cas des archives scientifiques Les archives scientifiques sont un contexte applicatif particulièrement vaste et représente une problématique relativement ancienne [167]. Dans le projet, nous avons limité ce contexte au cas particulier des cahiers de laboratoire numériques. Par nature, le cahier de laboratoire est une archive complexe dans le sens où il est à la fois une archive courante, semi-courante et potentiellement définitive. Il représente donc une sujet d étude particulièrement intéressante, car le système doit prendre en compte les contraintes associées à chacun de ces types d archives. Bien qu il existe plusieurs cahiers de laboratoire numériques actuellement commercialisés, ils reposent tous sur un modèle centralisé de type Clients/Serveur. Si cette approche offre aux institutions une meilleure visibilité sur la production scientifique de ses membres, elle réduit le caractère personnel du cahier de laboratoire pour les chercheurs. Ainsi, une approche P2P d un cahier de laboratoire numérique permettrait aux chercheurs de se réapproprier cet outil en d offrir aux chercheurs une solution à la fois plus d un cahier de laboratoire traditionnel tout en l enrichissant des nouvelles possibilités inhérentes au passage aux documents numériques. 91

108 Chapitre 4. Deux études de cas pour évaluer notre grille d analyse 4.3 Conclusion Les deux contextes présentés dans ce chapitre sont très différents l un de l autre. En tant que problématique émergente, les services à l habitat ont donné lieu à de nombreuses publications définissant finement ce contexte d application. En revanche, les systèmes actuellement déployés ou en cours de déploiement ne sont absolument pas documentés. Il est donc difficile, dans ce contexte, d avoir une idée précise sur les performances des différentes approches possibles et sur leur capacité à accueillir de très nombreux clients. L utilisation du modèle P2P est dans ce contexte une approche prometteuse, car ce type de système doit pouvoir gérer plusieurs millions de clients. À l inverse, l archivage scientifique est une problématique beaucoup plus ancienne n ayant donnée lien qu à peu d article de recherche récemment. De plus, même en se limitant au cas particulier du cahier de laboratoire numérique, l étude du domaine s avère difficile. En effet, les cahiers de laboratoire numérique actuellement disponible sont, le plus souvent, dédiés à des domaines de recherche particuliers, comme la biologie ou la chimie et très peu d entre eux ont fait l objet d articles de recherche [154]. Pourtant, malgré cette diversité de systèmes, on constate qu ils reposent tous exclusivement sur un modèle centralisé. Ainsi, la proposition d une solution basée sur le modèle P2P peut faire sens, car elle permettrait de lever les contraintes liées à une approche centralisée et surtout proposer une architecture plus en phase avec l organisation du travail de recherche. Dans les deux chapitres suivants, nous présenterons donc deux propositions de systèmes P2P élaborés à partir de notre grille d analyse pour répondre à chacun de ces deux contextes. 92

109 CHAPITRE 5 PROPOSITION D UN SYSTÈME P2P POUR UN FOURNISSEUR DE SERVICES À L HABITAT L objectif de ce chapitre est de présenter la démarche utilisée pour proposer un système P2P dans le cadre du projet industriel d un fournisseur de services à l habitat. Nous commençons par définir les besoins spécifiques à ce cas d utilisation afin de déterminer les objectifs du système. Nous étudions ensuite les systèmes P2P existants pouvant répondre à ces besoins. En effet, notre grille d analyse visant à être générique, elle ne tient pas compte des mécanismes particuliers ayant pu être développés pour répondre à des besoins spécifiques. Il est donc important d étudier cet existant afin de pouvoir intégrer les propriétés de ces mécanismes particuliers à notre proposition de système. À partir des informations dégagées dans ces deux premières parties, nous utilisons notre grille d analyse pour proposer un système P2P adapté aux besoins et contraintes d un système de fournisseur de services à l habitat. Ces besoins sont analysés en tenant compte des mécanismes issus de l existant afin de déterminer les propriétés auxquelles notre système P2P doit répondre. Ces besoins sont ensuite utilisés en entrée de notre grille d analyse pour déterminer les approches à utiliser au niveau de chacune des couches fonctionnelles composant le système. Enfin le système ainsi obtenu est comparé par l analyse à d autres approches qui ont été envisagées afin de valider la pertinence des résultats obtenus par notre grille d analyse. 93

110 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat 5.1 Besoins spécifiques associés à un système pour un fournisseur de services à l habitat À partir du modèle conceptuel d architecture de fournisseur de services à l habitat présenté en (Fig.), nous avons pu dégager certains enjeux qu une telle architecture doit relever. Ainsi, chacun de ces enjeux a été décliné sous la forme de besoins qui devront être pris en compte dans la conception d une nouvelle architecture de fournisseur de services au sein de l habitat. Ces besoins peuvent être séparés en deux grandes catégories, les propriétés de l architecture et les services de base que l architecture doit pouvoir supporter. Ainsi, nous présenterons ici ces différents besoins par rapport au modèle d architectures de services au sein de l habitat défini dans le chapitre précédent. Figure 5.1 Modèle générique d architecture de système de fournisseur de services à l habitat Besoins architecturaux Les besoins relatifs aux propriétés de l architecture correspondent à des caractéristiques intrinsèques que l on souhaite obtenir pour celle-ci. Ainsi, pour pouvoir répondre aux évolutions à la fois du nombre de clients, mais aussi du nombre de services proposés par la plateforme, il est nécessaire que celle-ci puisse passer l échelle. De même, l architecture doit pouvoir offrir des garanties sur la disponibilité des services Passage à l échelle L un des objectifs d une architecture de services au sein de l habitat est de pouvoir proposer ses services au plus grand nombre de clients. Cela induit donc une très forte augmentation de leur nombre, qui passerait d une centaine à plusieurs dizaines de millions en quelques années. Parallèlement à cette augmentation du nombre de clients, il est aussi 94

111 5.1. Besoins spécifiques associés à un système pour un fournisseur de services à l habitat prévu d enrichir les offres de service proposées. Le système doit donc pouvoir supporter cette augmentation du nombre de clients, mais aussi de services. L augmentation du nombre de clients et donc de sites entraîne des conséquences qui doivent être gérées pour que le système puisse passer à l échelle (Tableau 5.1). En premier lieu, cette augmentation impacte plus particulièrement le bus du système qui est amené à maintenir un plus grand nombre de connexions simultanées avec les sites. De même la quantité d information qui transite par ce dernier augmente avec le nombre de sites et peut donc finir par dépasser ses capacités. Enfin, les services sont aussi affectés par cette augmentation qui se traduit, à leur niveau, par une augmentation du volume d information à traiter. Pour ces derniers, en revanche, l utilisation de services déportés permet de limiter cette augmentation des informations à traiter par les services du fournisseur. En effet, les services déportés étant liés aux sites, ils ne sont pas affectés par l augmentation de leur nombre. Table 5.1 Influence de l augmentation du nombre de clients et de services sur le système Les sites Le bus Les services Augmentation du Augmentation du Augmentation du nombre de sites nombre de : volume d informations à traiter de messages de connexions simultanées Augmentation du Augmentation du Augmentation nombre de services nombre : du nombre de messages d informations collectées de services déportés de capteurs / actionneurs Parallèlement à l augmentation du nombre de clients, le système doit aussi pouvoir gérer l augmentation du nombre de services à destination des utilisateurs. Cette augmentation affecte fortement les sites. En effet, afin de proposer de nouveaux services il peut être nécessaire d ajouter de nouveaux capteurs/actionneurs sur les sites. Ainsi, l augmentation du nombre de à destination des utilisateurs finaux peut conduire à un accroissement du nombre de capteurs/actionneurs qui communiqueront avec la gateway. De plus, cette augmentation du nombre de capteurs/actionneurs implique aussi un accroissement de la quantité d information qui devra remonter vers le bus et donc de la bande passante nécessaire pour assurer cette remontée d information. Enfin, cette augmentation de la quantité d information se répercute directement sur le bus qui devra lui aussi supporter une quan- 95

112 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat tité de messages plus importante. Enfin, comme un service final pour l utilisateur est représenté dans le modèle par un ou plusieurs services au niveau de l architecture, l augmentation du nombre de services à destination des utilisateurs implique automatiquement un accroissement du nombre de services dans l architecture du système, qu ils soient au niveau du fournisseur ou déporté sur les sites. Les limites concernant le passage à l échelle de la gateway peuvent dépendre de l implémentation du réseau de capteur/actionneur. Ainsi, si les communications entre les capteurs/actionneurs sont centralisées au niveau de la gateway, le nombre de connexions simultanées que celle-ci peut supporter est une limite au passage à l échelle. De même, la quantité d information échangée entre la gateway et le bus peut aussi devenir un facteur limitant. Enfin, l ajout de nouveaux services déportés peut aussi limiter le passage à l échelle de la gateway dans le cas où il serait implémenté directement dans le même matériel. En effet, en procédant ainsi, les ressources matérielles seront partagées entre la gateway et les services déportés ce qui limite augmentation de leur nombre. Au niveau des services du fournisseur, ils devront pouvoir supporter l augmentation du nombre d informations collectées qui résulte de l augmentation du nombre de sites. Cela implique donc une augmentation de la capacité de traitement au niveau des services qui est nécessaire à la réalisation des services destinés aux utilisateurs. Enfin, le principal enjeu pour le système en termes de support du passage à l échelle se situe au niveau du bus qui doit à la fois supporter l augmentation du nombre de connexions qu il doit pouvoir gérer simultanément, mais aussi l augmentation du volume des messages. Si le nombre de connexions est directement lié au nombre de sites, le volume des messages qui transite par le bus dépend à la fois du nombre de sites, mais aussi du nombre de services. Ainsi, même si généralement, le nombre de connexions simultanées est le principal facteur limitant pour le support du facteur d échelle, le fait que le nombre de services applique un facteur multiplicatif à la quantité d information transmise par les sites vers le bus peut aussi devenir problématique Haute disponibilité La disponibilité des services est importante fournis aux clients est un facteur important, qui peut influencer fortement la nature des services qui pourront être proposés. Ainsi, il est nécessaire que le système puisse être hautement disponibles afin de pouvoir soutenir n importe quel type de services. Cela implique de pouvoir gérer les différents incidents qui pourraient remettre en cause la disponibilité du système pour les clients (Tableau 5.2). On peut distinguer deux principales atteintes à la disponibilité du système, les pertes de disponibilité globale qui touchent l ensemble du système, et les pertes de disponibilité locale qui ne touchent que des groupes restreints de sites. Les pertes de disponibilité globale sont principalement dues à des défaillances au niveau du bus ou des services. En effet, si le bus n assume plus la transmission des messages entre les sites et les services, l ensemble du système devient indisponible. De même, si un 96

113 5.1. Besoins spécifiques associés à un système pour un fournisseur de services à l habitat service tombe en panne, l ensemble des services qui en dépendent devient indisponible. Il est donc indispensable, pour assurer la haute disponibilité du système, de mettre en œuvre des mécanismes permettant d assurer que les pannes matérielles ou logicielles n affectent pas la disponibilité ni du bus, ni celle des services. En revanche, même en cas de perte globale de disponibilité, les services déportés qui ne nécessitent pas de communication avec d autres services hébergés par le fournisseur peuvent continuer à fonctionner. Les pertes de disponibilité locale viennent principalement de défaillances au niveau des sites. Il existe deux défaillances qui peuvent entraîner une perte de disponibilité d un site, une panne au niveau de la gateway et la perte de la connexion avec le bus. Dans ces cas, le site devient inaccessible pour le bus. Enfin, la panne ou la déconnexion du réseau interne au site d un capteur/actionneur peut compromettre le bon fonctionnement d un ou plusieurs services qui lui sont associés. En effet, la perte de capteurs peut empêcher la prise de décision par le système, et l absence d actionneur peut compromettre l exécution d une action à distance. Enfin, une panne au niveau d un service déporté peut aussi compromettre la disponibilité de l ensemble des services destinés aux utilisateurs finaux, qui lui sont associés. Table 5.2 Présentation des différents événements pouvant affecter la disponibilité du système Les sites Le bus Les services Perte globale de la disponibilité du système Perte locale de la disponibilité du système Perte de la connexion avec le bus du fournisseur de services Panne de la gateway Panne des capteurs / actionneurs Panne d un service déporté Panne partielle ou totale pouvant compromettre son fonctionnement Panne d un ou plusieurs services Considération financières L un des enjeux principaux du projet est de limiter les coûts nécessaires pour la création du système. En effet, avec comme objectif pour le système de gérer plusieurs millions de sites, les coûts liés à l infrastructure deviennent particulièrement importants. À cette 97

114 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat échelle, le modèle Clients/Serveur montre ces limites en termes de flexibilité, de tolérance aux pannes, mais surtout s appuie sur du matériel dédié particulièrement onéreux. En conséquence, il devient intéressant de chercher des solutions alternatives afin de pouvoir limiter le coût global du système. Une infrastructure Clients/Serveur pour un système à cette échelle repose généralement sur l utilisation de nombreux équilibreurs de charge pour repartir celle-ci sur de nombreux serveurs fonctionnant en parallèle. De plus, afin d améliorer la tolérance aux pannes d un tel système, il est nécessaire d avoir plusieurs serveurs et équilibreurs de charge en réserve pour pouvoir remplacer ceux qui tombent en pannes. Une infrastructure reposant sur un modèle Clients/Serveur demande donc d importants investissements pour être efficace à cette échelle. Enfin, ce type de modèle reposant sur des fermes de serveurs, celles-ci doivent être reliées à Internet par plusieurs connexions à très haut débit afin de pouvoir recevoir la quantité d information produite par les sites. Ces connexions doivent, elles aussi, être redondées si l on souhaite que le système puisse supporter la perte de l une d entre elles sans que les services ne s en trouvent dégradés. Au-delà du coût de l infrastructure, les coûts de communications doivent aussi être pris en compte. En effet, en fonction des technologies utilisées pour permettre aux gateway de communiquer avec le SI du fournisseur de services, il est possible que ces communications aient un coût. Ainsi, il faut que le système limite la quantité de messages qui seront échangés afin de réduire le plus possible le coût potentiel de ces communications. L un des objectifs du système est de trouver un moyen de limiter ces coûts. Il est donc nécessaire que le système proposé soit moins onéreux qu un même système basé sur une architecture Clients/Serveur Besoins fonctionnels L objectif de l architecture est de permettre de soutenir une grande variété de services à destination des habitats des clients. Cette architecture devant être agnostique aux types de services pouvant être déployés dessus, elle doit donc permettre l exécution de certaines fonctionnalités qui serviront de briques de bases pour les futurs services fournis aux clients. Ainsi, certaines de ces fonctionnalités de base ont déjà été identifiées comme la gestion de différents modes de communication ou encore la capacité à superviser le système Gestion des communications de groupe Afin de pouvoir fournir une vaste gamme de services dont les besoins en termes de communication peuvent varier, le système doit pouvoir supporter différents modes de communication entre les sites et le bus. En effet, certains services, comme la gestion de la consommation électrique des clients, peuvent nécessiter l envoi de messages à des groupes de clients alors que des services, comme la gestion du chauffage à distance, nécessite l envoies de message directement à des capteurs/actionneurs particuliers d un seul site. Ainsi, 98

115 5.1. Besoins spécifiques associés à un système pour un fournisseur de services à l habitat on peut distinguer plusieurs types de communications que le système devra être capable de supporter. communication entre le bus et un site particulier ; communication entre le bus et un capteur/actionneur d un site en particulier ; communication entre le bus et un groupe de sites définis ; communication entre le bus et un nombre défini de sites possédants des propriétés communes. L architecture doit permettre chacun de ces types de communication afin de pouvoir supporter une importante variété de services. Il est donc nécessaire de gérer plusieurs niveaux d adressage des composants du système afin de pouvoir contacter à la fois un site dans son ensemble aussi bien qu un capteur/actionneur particulier. De même, il faut pouvoir fournir des outils pour gérer les communications de groupe qu ils soient prédéfinis ou créé dynamiquement Supervision Le système doit être supervisé afin qu à tout moment il soit possible de connaître son état de fonctionnement et pouvoir agir sur celui-ci. Ce besoin de supervision se décline en deux principales fonctionnalités, la capacité à interroger à tout moment n importe lequel nœud du système pour connaître son état et la détection des pannes. La première fonctionnalité consiste à la fois à interroger un nœud du système en particulier ou un groupe de nœuds afin de pouvoir relever, à la demande, son état général ou seulement des informations particulières. La deuxième fonctionnalité vient compléter la première en fournissant une détection et notification des pannes et autres événements pouvant impacter le bon fonctionnement du système. Ainsi, à chaque fois qu un nœud du système se retrouve dans une situation jugée impactant pour le système, une notification est envoyée aux personnes chargées de la supervision. La liste des situations qui doivent faire l objet d une notification auprès des superviseurs doit être définie au préalable. L ensemble de ces deux fonctionnalités permet aux personnes en charge de la supervision du système de pouvoir à la fois visualiser l état des différents composants de ce dernier, mais aussi d être informées des événements pouvant nécessiter leur intervention Adéquation d un système P2P avec les besoins Les besoins architecturaux justifient à eux seuls l utilisation du modèle P2P pour le développement d un tel système. En effet, le système d un fournisseur de services est par nature distribué et nécessite de supporter le passage à l échelle en nombre de clients et de services tout en étant tolérant aux pannes. Ces propriétés sont justement celles qui ont guidé le développement des systèmes P2P, car elles ne pouvaient être efficacement prises 99

116 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat en charge par les systèmes reposant sur le modèle Clients/Serveur. L enjeu de ce cas d étude est donc de définir un système P2P capable de prendre en charge les besoins fonctionnels. En effet, si il est possible de répondre aux besoins architecturaux par la simple utilisation du modèle P2P, le système doit pouvoir prendre en charge les fonctionnalités qui ont été définies. Il est donc nécessaire d étudier les systèmes P2P existants qui ont été développés pour prendre en charge ces fonctionnalités. 5.2 Étude des systèmes P2P existants répondant aux besoins fonctionnels Les deux besoins fonctionnels du système sont la communication de groupe et la supervision. Ces besoins revoient aux systèmes P2P de multicast applicatif et de supervision qui existent dans la littérature. Chacun de ces domaines est analysé pour déterminer les différentes approches et mécanismes existants ainsi que leurs performances. Nous ne présenterons ici qu un résumé de ces analyses qui sont mise en annexe si le lecteur désire des informations plus complètes sur le sujet. À partir des résultats obtenus au cours de cette analyse, nous évaluerons l adéquation de l existant avec nos besoins pour définir quels mécanismes peuvent être réutilisés dans notre système Les systèmes de multicast applicatif en P2P Le modèle P2P est souvent utilisé pour réaliser des systèmes de muticast applicatif (ou ALM). En effet, le principe de ces systèmes étant de diffuser des messages à toutes les membres d un groupe, le modèle P2P permet d utiliser les pairs participants au système pour retransmettre les messages à d autres pairs et ainsi répartir la charge sur l ensemble des membres du groupe. Il existe deux types approches pour réaliser un système de multicast applicatif en P2P : Les approches par arbre et les approches par rumeur. Les approches par arbre consistent à guider l organisation de l overlay reliant les pairs de sorte à limiter le nombre de retransmissions nécessaire pour diffuser un message à l ensemble des pairs. Pour ce faire, ces systèmes construisent un arbre reliant les pairs du système entre-eux qui servira d overlay pour la diffusion des messages [127, 20, 116, 35, 39]. Si les approches par arbre permettent de limiter grandement le nombre de retransmissions nécessaire pour diffuser un message à l ensemble des pairs du système, elles sont aussi peu tolérantes aux pannes [155]. En effet, quand l arbre doit être reconstruit, par exemple après le départ d un pair, un système reposant sur une approche par arbre ne peut garantir que l ensemble des pairs recevra le message. Les approches à base de rumeur reposent sur l utilisation d algorithmes épidémiques pour diffuser les messages sur l ensemble des pairs d un groupe. Dans ce type d approche, les pairs du groupe sont interconnectés les uns aux autres par un unique overlay. Quand un pair du groupe souhaite diffuser un message aux autres pairs, il choisit aléatoirement 100

117 5.2. Étude des systèmes P2P existants répondant aux besoins fonctionnels un de ses voisins et lui envoie le message. Ce pair devient infecté par la rumeur. Ainsi, au tour suivant, lui et le pair initiateur du message choisissent chacun un voisin pour lui envoyer le message et l infecter à son tour [63, 29, 87, 119]. Les approches par rumeur sont particulièrement robustes, car elles reposent sur une importante redondance dans la retransmission des messages dans le système. Ainsi, même si le nombre de messages envoyés par chaque pair reste modéré [63] est bien supérieur à celui d une approche par arbre. De plus, le mécanisme de retransmission reposant sur une succession de tours, les systèmes basés sur une approche par rumeur impliquent automatiquement une latence assez importante dans la diffusion des messages. Ainsi, aucune n approche ne permet de répondre totalement à nos besoins. Comme le montre le tableau 5.3, aucun système existant ne permet d à la fois avoir une bonne tolérance aux pannes, une faible latence dans la transmission des messages et de limiter le nombre de messages échanger. Ainsi, bien que le nombre de messages échanger et la latence des transmissions des approches par arbre soient satisfaisants, leur faible tolérance aux pannes ne permet pas d obtenir une haute disponibilité pour le système. À l inverse, si la tolérance aux pannes des approches par rumeur pouvait convenir pour notre système, la latence qu elles impliquent ainsi que le nombre de messages devant être échangé par les pairs sont beaucoup trop élevés Les systèmes de supervision en P2P La supervision consiste à collecter des informations sur l ensemble des composants d un système afin de créer une vue d ensemble de ce système. Dans les systèmes P2P, ce sont les pairs qui collectent les informations sur l ensemble des pairs du système. Pour créer la vue d ensemble, ses systèmes utilisent généralement des fonctions d agrégations comme des sommes ou des moyennes afin de contenir la taille des informations échangées par les pairs. Ce type d informations agrégées n est pas suffisant pour les besoins d un fournisseur de services à l habitat qui doit pouvoir à tout moment déterminer l état exact d un habitat pour lequel il fournit un service. Ainsi, nous étudions la capacité des systèmes de supervision en P2P à supporter la collecte d informations non agrégées pour déterminer si les mécanismes qu ils mettent en œuvre peuvent répondre à nos besoins. Il existe trois types approches de construction de systèmes P2P de supervision : les approches par arbre, par rumeur et les approches hiérarchiques. Dans une approche par arbre, le système repose sur un overlay qui sert à maintenir une structure de communication en arbre entre les pairs. Ainsi, les pairs en bas de l arbre envoient les informations sur leur état à leur parent dans l arbre qui agrège ces informations avec celles relatives à son état puis les envoie à son propre parent. Cette procédure se répète jusqu à ce que l ensemble des agrégats atteigne le pair racine de l arbre et que celui-ci calcule la vue globale du système [65, 161, 169]. L avantage de cette approche est qu elle limite le nombre de retransmissions des messages entre les pairs ainsi que le temps nécessaire pour créer la vue globale sur le système. En revanche, cette approche n est 101

118 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat pas tolérante aux pannes, car plus un noeud de l arbre est proche de la racine de racine, plus sa panne pourra compromettre le résultat de l agrégat. De même, la racine étant le seul pair à calculer l agrégat final, il forme un point unique de rupture pour l ensemble du système. Enfin, dans le cas d une collecte de données non agrégées plus un pair sera proche de la racine, plus il recevra une quantité de données importante. Cette approche ne permet donc de supporter le passage à l échelle que pour la collecte de données agrégées. Table 5.3 Comparaison des systèmes de multicast applicatif Passage à l échelle Tolérance Équilibre de Nombre total aux pannes la charge de messages échangés Approches par arbre Narada [39] Non (O(n) information Non Non O(n) collectée pour maintenir l arbre) Scribe [35] Oui (O(1) états Non Non O(n) conservés par pair et O(1) messages échangés correspondant au nombre de fils dans l arbre) ALMI [127] Non (serveur central Non Non O(n) collectant O(n) informations pour maintenir l arbre) TBCP [116] Oui (O(1) correspondant Non Non O(n) au nombre de fils de chaque pairs) Approches à base de rumeur Araneola [119] SCAMP [63] Oui (O(1) messages échangés pour la diffusion et O(1) informations à maintenir par pairs) Oui (O(log(n)) messages échangés pour la diffusion et O(1) informations à maintenir par pairs) Oui Oui O(k n) avec k le nombre de liens par pairs Oui Oui O(n*log(n)) 102

119 5.2. Étude des systèmes P2P existants répondant aux besoins fonctionnels Les approches par rumeur consistent en l échanger de données entre les pairs du groupe afin qu ils puissent déterminer des informations globales sur l ensemble du système. Le mécanisme d agrégation d une approche par rumeur se divise en un nombre de tours données. Tous les tours, chaque pair échange ses informations sur l état du système avec un autre pair du système afin que chacun d eux calcule l agrégat de ses informations. Au bout d un nombre de tours donné, généralement proportionnel à O(log(n)), avec n le nombre de pairs présents dans le système, chacun des pairs possède l agrégat de l ensemble des états des pairs du système [89, 73, 82]. Une approche par rumeur est très tolérante aux pannes, car tous les pairs réussissent à calculer l agrégat de l ensemble des informations, même si plusieurs départs de pairs ont lieu pendant l exécution du mécanisme. En revanche, cette approche nécessite qu une grande quantité d informations soit échangée par chacun des pairs du système. De même, le mécanisme se déroulant sur plusieurs, le temps nécessaire pour le calcul de l agrégat global par chaque pair est très élevé par rapport à une approche par arbre. Enfin, dans le cas d une collecte d informations brutes, une approche par rumeur conduirait à ce que chaque pair collecte des informations sur l ensemble des pairs présent dans le système, ce qui implique qu une telle approche ne pourrait pas supporter le passage à l échelle en nombre de pairs. Enfin, les approches hiérarchiques reposent sur une segmentation sur plusieurs niveaux des groupes de pairs à superviser. Ainsi, le système sera séparé en plusieurs groupes indépendants de sorte à calculer des agrégats pour chacun de ses groupes [160, 141, 27]. L avantage d une telle approche est qu elle permet d utiliser des approches différentes entre chaque groupe pour calculer les agrégats. Ainsi, certains systèmes utilisent une approche par rumeur pour calculer les agrégats au sein d un même groupe et utilisent une structure en arbre pour gérer la communication entre les groupes [141]. Une approche hiérarchique permet donc d avoir une plus grande flexibilité que les approches par arbre et par rumeur, car elle permet de les combiner pour composer un système offrant le compromis recherché. En revanche, cette hiérarchisation implique un déséquilibre de la charge entre les pairs, car certains d entre eux doivent faire partie de plusieurs groupes afin de calculer l agrégat des informations sur l ensemble du système. De même, elles possèdent les mêmes limites que les approches utilisées pour le composer. Ainsi, aucune approche hiérarchique ne permet de supporter le passage à l échelle pour la collecte de données brutes. Comme le montre le tableau 5.4, aucun système P2P de supervision ne supporte la collecte de données concaténées, qui permet de percevoir des phénomènes locaux masqués par l agrégation des données, tout en supportant le passage à l échelle. De plus, comme pour les systèmes de multicast applicatif, les approches par arbre ne permettent pas de tolérer les pannes et les approches par rumeurs génèrent une quantité trop importante de messages. En revanche, on peut voir que les approches hiérarchiques se comportent relativement mieux que les autres même si elles impliquent que la charge entre les pairs soit déséquilibrée. 103

120 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat GAP [44, 65, 84] SDIMS [170, 169] Kempe [89] Astrolabe [160] Binzenhöfer [27] Table 5.4 Comparaison des systèmes d agrégation Passage à Tolérance Équilibre de la charge l échelle aux pannes Approches par arbre Agrégation Oui (O(1)) Non Non, les pairs feuilles sont moins chargés que les autres pairs Données Non (O(n)) Non, plus un pair est brutes proche de la racine plus il est chargé Agrégation Oui Non, mais Oui la propagation des erreurs est limitée Données brutes Agrégation Données brutes Agrégation Nombre total de messages échangés O(n) O(n 2 ) Non Non, plus un pair est proche de la racine,? plus il est chargé Approches par rumeur Oui Oui Oui O(n log(n)) (O(log(n))) Non O(n 2 log(n)) (O(n log(n))) Approches hiérarchiques Oui (O(log(n))) Oui Non, les représentant de chaque groupe sont plus chargés que les autres pairs du groupe Données brutes Non (O(n log(n))) Agrégation Oui (O(1)) Oui Non, le pair initiateur est plus chargé que les autres pairs Données Non (O(n)) Non, plus un pair est brutes proche de la fin d une sous-section de l anneau, plus il est chargé? O(n log(n)) O(n 2 log(n)) O(n) O(n 2 ) 104

121 5.3. Proposition du système Analyse de l adéquation des systèmes existants par rapport au cas d étude Les systèmes P2P existants, qu ils soient de multicast applicatif ou de supervision, ne permettent pas de répondre à nos besoins. En effet, soit ils n en sont pas tolérants aux pannes, soit ils nécessitent l échange d un très grand nombre de messages pour fonctionner. De plus, aucun système P2P de supervision ne permet de collecter des informations plus précises que des données agrégées. En revanche, cette étude nous montre qu un modèle hiérarchique semble plus efficace pour atteindre le compromis qui nous intéresse. Ainsi, il est nécessaire de proposer un nouveau type de système P2P afin de pouvoir répondre au besoin spécifique d un système P2P pour un fournisseur de services à l habitat. 5.3 Proposition du système Notre objectif est d utiliser notre grille d analyse pour définir les systèmes P2P les plus adaptés pour répondre aux besoins d un fournisseur de services à l habitat. Pour ce faire, déterminons, à partir des besoins exprimé par le projet, les propriétés et les contraintes qui devront être prises en compte dans le choix des approches à retenir pour chacune des couches fonctionnelles. À partir de cet ensemble de propriétés et de contraintes, nous utilisons notre grille d analyse pour déterminer les approches les plus efficaces au niveau des couches application, indexation et adaptation du réseau hôte du système. Une fois toutes les approches choisies, elles sont assemblées afin de présenter une vue d ensemble de notre système final Définition des propriétés et contraintes à considérer Nous analysons ici les différentes contraintes et besoins exprimés pour en extraire l ensemble des propriétés qui sera utilisé en entrées de notre grille d analyse. Nous distinguons pour ce cas d utilisation, deux types de propriétés : les propriétés architecturales et celles liées aux besoins. En effet, certaines de ses propriétés sont directement données par l architecture d un fournisseur de services à l habitat défini en alors que d autres sont issues de l analyse des besoins en Propriétés architecturales Un système de fournisseur de services à l habitat possède plusieurs propriétés architecturales inhérentes à leur fonctionnement. En effet, leur architecture doit être partagée entre les habitats des clients et le fournisseur de services lui-même. Ainsi nous distinguons deux principales propriétés. 105

122 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat une partie de l infrastructure est distribuée au niveau des habitats des clients afin de collecter les informations et appliquer les actions définies par le système ; une partie de chaque service proposé aux clients doit être calculé au niveau des centres de calculs gérés par le fournisseur de services. La première propriété est évidente, car il n est pas possible d offrir des services à un habitat si une partie de l architecture du système n est pas directement présente dans celui-ci. La deuxième propriété repose sur des problématiques de sûreté du système et de propriété intellectuelle. En effet, il est nécessaire de centraliser une partie des calculs de chaque service au niveau de centres de calculs gérés par le fournisseur lui-même afin de préserver les secrets sur les traitements effectués sur les informations personnelles des clients. De plus, l architecture des centres de calculs dépasse le cadre de notre travail, le système devant juste être capable d en gérer un ou plusieurs. Enfin, aucune contrainte n est associée au bus de services chargé de la communication entre les habitats et le fournisseur de services. Ainsi, ce dernier peut aussi bien être distribué au niveau des habitats des clients ou centralisé chez le fournisseur de services Propriétés liées aux besoins Chaque besoin que nous avons défini doit être analysé pour en extraire les contraintes qu ils induisent. En effet, chaque besoin peut être défini comme un ensemble de contraintes auquel le système doit répondre. Ce sont ces contraintes qui seront utilisées dans notre modèle pour définir les approches les plus adéquates pour l implémentation de notre système Passage à l échelle Le besoin de support du facteur d échelle peut directement être pris comme une propriété que devra posséder le système. Ainsi, ce dernier doit pouvoir supporter une augmentation du nombre d habitats et de services sans avoir à remettre en cause son fonctionnement. En revanche, ce support du passage à l échelle peut être soutenu par l ajout de nouveau matériel si cela peut être effectué à chaud. Ce besoin porte principalement sur le bus de services. En effet, l architecture des centres de calculs dépassant le cadre de ce travail, le support du passage à l échelle peut donc se résumer au fait que le bus de services doit pouvoir supporter une augmentation du nombre d habitat et de centre de calcul qui y est connecté Tolérance aux pannes La haute disponibilité correspond à un besoin de tolérance aux pannes du système. Ainsi, le système doit garantir l accès aux services des clients même en cas de pannes matérielles au niveau du bus de services et des centres de calculs. En effet, il n est pas possible de fournir des services au niveau d un habitat si le matériel présent dans l habitat ne fonctionne pas. 106

123 5.3. Proposition du système Les centres de calcul dépassant le cadre de ce travail, la tolérance aux pannes du système consiste donc à garantir que le bus de services assure la transmission des messages entre les habitats et les centres de calculs même en cas de pannes d un ou plusieurs de ses composants Échanges de messages Les besoins de communications de groupe et de supervision du système peuvent être résumés à un ensemble de propriétés sur la capacité de diffusion des messages du système. En effet, les informations issues des habitats doivent être transmises aux centres de calculs et les ordres issus de celles-ci doivent être diffusés à des ensembles d habitats. On distingue plusieurs situations de diffusion de messages que le système doit pouvoir gérer : l envoi d informations à l initiative d un habitat sur son état à un type de centre de calcul prédéfini ; l envoi d ordre à l initiative d un centre de calcul à un ensemble d habitats partageant des propriétés communes. Dans le cas des envois d ordres, les ensembles d habitats peuvent être définis de plusieurs façons afin de répondre à une grande variété de situations. Ainsi, un ensemble d habitats peut être tous les habitats possédant les propriétés voulues ou seulement un nombre déterminé d habitats possédants les propriétés les plus proches possibles de propriétés définies dans la requête. De plus, si l ensemble des propriétés pouvant être utilisées dans une requête est assez large, un nombre plus restreint peut être considéré comme fondamental. En effet, la localisation géographique ou le type de contrat de service souscrit pour l habitat seront utilisés dans l ensemble des requêtes pouvant être générées. En plus de la diffusion de messages, le système doit gérer des communications plus ponctuelles associées à certains services ou à des situations incidentielles. Ces communications sont par nature imprévisible, elles sortent du modèle de diffusion de messages précédemment cité. Ainsi, deux autres situations de communications doivent être prises en compte : l envoi de requêtes depuis un habitat vers un type de centre de calcul prédéfini ; l envoi d une requête sur les informations relatives à l état d un habitat données depuis un centre de calcul. Ces quatre types d échanges correspondent à l ensemble des besoins de communications du système Qualité de service Le système doit pouvoir gérer plusieurs types de messages possédant des contraintes différentes. En effet, le système doit permettre la trans- 107

124 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat mission rapide de messages tels que des alarmes alors que les collectes périodiques d informations sur l état des habitats peuvent tolérer du retard dans ses transmissions. Ainsi, on peut définir deux propriétés relatives à ce besoin de qualité de services. La première est que le système doit pouvoir différencier des catégories de messages associées à différentes contraintes quant à leur délai de transmissions. La deuxième est de permettre la transmission rapide de certains messages. Ainsi, le système doit pouvoir garantir une latence faible des transmissions entre les habitats et les centres de calculs Limitation du coût global L utilisation du modèle P2P ne doit pas entrainer une augmentation du coût global du système. Ainsi, le système doit limiter le plus possible son besoin en infrastructure ainsi qu en communication. Pour ce dernier point, on considère que les communications entre les habitats peuvent être payantes pour le fournisseur de services, car elles peuvent utiliser des technologies comme le GPRS ou l UMTS. Ainsi, l on distingue deux principales sources de coûts que le système doit limiter le plus possible : les communications à l initiative des habitats des clients ; la quantité d équipement nécessaire à la charge du fournisseur de services. Pour le dernier point, nous ne considérons que le bus de services, car les centres de calcul sortent du cadre de notre travail Utilisation de notre grille d analyse À partir des propriétés que nous venons de définir, nous utilisons notre grille d analyse pour déterminer le type de système P2P le plus adapté à nos besoins. Ainsi, pour chaque couche fonctionnelle qui compose le système, nous nous utilisons notre grille pour associer ces propriétés aux approches possibles. Nous présentons ensuite les approches qui se dégagent et analysons les perspectives qu elles apportent Couche application La principale fonctionnalité considérée pour la couche application est le partage de données. En effet, bien qu il puisse être intéressant que le système puisse supporter la distribution des traitements, ces derniers sont considérés comme dépassant le cadre de cette étude. En effet, les traitements relatifs aux services que le système doit proposer n ont pas été définis par le partenaire industriel du projet, il est donc impossible de préjuger de la pertinence de la distribution des traitements. Les trois propriétés ayant donc un impact sur le choix d une approche au niveau de la couche application sont la qualité de services, les échanges de messages et la limitation 108

125 5.3. Proposition du système du coût global. On peut constater qu une partie des échanges de messages peuvent supporter la diffusion de données, car ils impliquent une connaissance préalable de pairs destinataire des messages. Ainsi, l envoi d informations depuis les habitats ou l envoie d ordres depuis les centres de calculs peuvent supporter une approche de diffusion de données. Dans les deux cas, la réduction de la latence permet de répondre aux besoins de qualité de services, mais aussi aux besoins de réductions du coût global dans le sens où moins d échanges de données sont nécessaires dans une approche par diffusion que par collecte. Le stockage des connaissances préalables sur les destinataires des messages dépend de la nature des messages eux-mêmes. En effet, si les habitats connaissent exactement les types de centres de calculs qui sont destinataire de leurs informations, les groupes d habitats ciblés par les envois d ordres peuvent changer en fonction des propriétés des habitats désirés. Ainsi, si un habitat peut maintenir une liste des destinataires des informations qu il produit, la diffusion d ordres issue des centres de calculs doit être gérée comme une requête spécifique par le bus de services. La couche d adaptation du réseau hôte ou d indexation devra donc prendre en charge une recherche d habitat par propriétés. Le cas des requêtes ponctuelles, qu elles soient à l initiative des habitats ou des centres de calculs ne permet pas d utiliser la diffusion de données, car le destinataire de la requête ne peut être connu à l avance. Le système doit donc supporter à la fois de la diffusion de données et de la collecte afin de répondre aux besoins qui ont été définis Couche d indexation En analysant les besoins d un fournisseur de services à l habitat, on constate que les ressources gérées par le système sont les habitats et les centres de calculs. En effet, les habitats peuvent être vus comme des ensembles de capteurs/actionneurs et les centres de calculs comme des ressources abstraites comme des services. Ainsi, la gestion des recherches sur les habitats et les centres de calculs au niveau de la couche d indexation est plus adaptée qu au niveau de la couche d adaptation du réseau hôte qui ne gère que la découverte des pairs présents dans le système. Cette dissociation des ressources et des pairs permet de laisser plus de libertés dans le choix des approches et donc d optimisations. Ainsi, l objectif de cette couche fonctionnelle est de retrouver les pairs hébergeurs des ressources définies dans les requêtes. On définit donc deux types de ressources abstraites : les habitats et les services. En effet, d un point de vue de la recherche, un habitat est composé des données sur son état ainsi que de donnée sur l état des actionneurs. Un ordre revient alors à changer l état d un actionneur. Pour les services, ils sont vus comme des programmes qui reçoivent des données en entrées et renvoient des données traitées en sorties. Si il est possible de définir des ensembles de propriétés communes à l un ou l autre de ces types de ressources, aucune de ces propriétés n est commune aux deux. De même, le besoin de recherche par propriétés est plus contraignant pour les recherches sur les 109

126 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat habitats que pour celles sur les services. En effet, s il n est nécessaire de ne trouver qu un seul service répondant aux critères de la requête, la recherche des habitats doit pouvoir être complète ou contenir un minimum d habitats y répondant en fonction des cas. Afin d avoir plus de liberté dans le choix des approches, il est donc préférable d avoir deux mécanismes de recherche indépendants, chacun pour un type de ressources. Ainsi, en tenant compte des besoins de passage à l échelle, de tolérance aux pannes et de recherche exacte par propriétés, l approche la plus adaptée pour indexer les habitats est l utilisation d un index distribué avec sémantique. En effet, c est l approche qui est la plus adaptée par rapport à ces quatre critères (Tableau 5.5). Table 5.5 Choix d une approche pour l indexation des habitats Index global Index global Index locaux Index partagés index distribué index distribué centralismantiqumantique répliqué sans sé- avec sé- Passage à l échelle Tolérance aux pannes Par propriétés Compétude De même, en considérant que la recherche de services se fait sur une seule propriété, nos besoins correspondent alors au passage à l échelle, la tolérance aux pannes et une recherche exacte tolérante aux faux négatifs. Cela correspond donc à une approche basée sur un index distribué sans sémantique (Tableau 5.6). Ces deux approches reposant sur un index distribué, elles possèdent les mêmes synergies avec les approches de la couche d adaptation du réseau hôte. Ainsi, il n est pas nécessaire d avoir deux approches différentes au niveau de la couche d adaptation du réseau hôte pour soutenir ces deux approches d indexation. 110

127 5.3. Proposition du système Table 5.6 Choix d une approche pour l indexation des services Index global Index global Index locaux Index partagés index distribué index distribué centralismantiqumantique répliqué sans sé- avec sé- Passage à l échelle Tolérance aux pannes Recherche exacte Faux négatif Couche d adaptation du réseau hôte L objectif de la couche d adaptation du réseau hôte est de fournir aux pairs les informations nécessaires pour qu ils puissent communiquer les uns avec les autres. Ainsi, la première question qui se pose est de savoir qui sont les pairs qui composent le système. En effet, la couche d indexation n impose aucune contrainte quant à la nature des pairs qui composent le système, la seule restriction étant que les habitats fassent partie du système. Deux choix sont alors possibles : faire soutenir le système par la mutualisation des ressources des habitats ou utiliser des serveurs hébergés par le fournisseur de service pour former un réseau de super-pairs, les habitats devenant des pairs feuilles. Chacune de ces deux approches possède des avantages et des inconvénients aux regards des besoins qui ont été définis. En effet, une approche basée sur les habitats comme seules pair du système permet de ne pas avoir de coûts d infrastructure et de garantir un support du passage à l échelle en nombre d habitats. En revanche, comme nous le montrent notre étude en 5.2 sur les systèmes de multicast applicatif et de supervision P2P, les habitats devront échanger un grand nombre de messages afin de pouvoir mener à bien les services souhaités. De même, le passage à l échelle en nombre de centres de calculs est limité par la quantité de ressources cumulées des habitats présents dans le système, qui dépend donc du nombre d habitats présent ainsi que des ressources mises à disposition par chacun de ces habitats. À l inverse, une approche hiérarchisée avec un réseau de serveurs permet de réduire la quantité de messages envoyés par les habitats ainsi que le diamètre de l overlay et donc la latence des transmissions. De même, si le support du passage à l échelle ne peut se faire que par l ajout de nouveaux super-pairs, le système supporte à la fois l augmentation du nombre d habitats et de centres de calculs. En revanche, cette approche impose un coût d infrastructure, car elle nécessite l achat de serveurs par le fournisseur de services à l habitat. 111

128 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat Nous décidons de retenir l approche hiérarchisée basée sur un réseau de serveur, car elle nous semble offrir le plus de possibilités en terme d optimisation. De plus, si elle impose un coût d infrastructure plus élevé, celui doit être mis en regard du coût des communications des habitats. Maintenant que la nature des pairs qui composent le système a été définie, il faut déterminer l approche la plus efficace à utiliser par rapport aux besoins. De par le besoin de support du passage à l échelle et de tolérance aux pannes, il n est pas possible d utiliser un serveur d adressage. De plus, au vu des choix retenus au niveau de la couche d indexation, le schéma de découverte des pairs le plus adapté est celui par identifiant. En effet, l identifiant attribué à chaque pair peut être utilisé comme des coordonnées de l espace métrique créé par la couche d indexation et ainsi associer un pair à la partie de l index qu il héberge. Ainsi, à partir du tableau 5.7, il est possible de déterminer qu une approche structurée, qu elle soit hiérarchisée ou pas, est la plus adaptée. Table 5.7 Types d approches associées aux besoins et contraintes dégages Serveur d adressagchisturturé Overlay simple Overlay hiérar- Overlay struc- Overlay struc- et hiérarchisé Passage à l échelle Tolérance aux pannes Par identifiant Nombre de messages Latence de la recherche Latence de la transmission Enfin, comme nos pairs sont de nature très hétérogène, avec des serveurs et des habitats, il est préférable de hiérarchiser l overlay, avec les serveurs sont les super-pairs de notre système et les habitats les pairs feuilles. En effet, même si il est difficile de réduire 112

129 5.3. Proposition du système la latence des transmissions dans ce type d overlays à cause des nombreuses contraintes imposées dans le choix des liens entre les pairs, on peut considérer que la latence des communications entre les serveurs du fournisseur de services devrait rester faible. Ainsi, le temps de latence dans les transmissions repose principalement sur les communications entre un habitat et le serveur qui en est responsable, ce qui rapproche le systèmes des performances en termes de latence du modèle Clients/Serveur Vue d ensemble du système Notre système se compose de trois principales entités (Fig. 5.2) : les centres de calculs du fournisseur reliés au bus de services ; le bus de services hébergé par un réseau de serveurs maintenu par le fournisseur ; les habitats des clients composés d un réseau de capteurs/actionneurs relié au bus de services par une gateway. Figure 5.2 Représentation du système avec les trois types d entités qui le compose 113

130 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat Ce système repose sur un overlay hiérarchique avec un type de pairs pour chacune de ces entités. Le coeur du système repose sur le réseau de serveurs qui compose le bus de services auquel les centres de calculs et les gateways des habitats sont reliés. Le bus de services utilise un overlay structuré pour organiser les communications entre les serveurs qui le compose. Cet overlay utilise un espace métrique à N dimensions pour se structurer. Cet espace métrique est aussi utilisé pour indexer les habitats en associant chacune des N dimensions à une propriété définissant un habitat (Fig. 5.3). Ainsi, la position de chaque habitat dans l espace métrique sera définie par ses caractéristiques relative aux propriétés retenues. De même, des connexions aux centres de calculs sont placées dans l espace métrique de façon aléatoire afin de pouvoir communiquer avec plusieurs serveurs différents du bus de services. De plus, en plaçant ces connexions aux centres de calculs dans l espace métrique, ces derniers ne sont pas liés à un pair particulier, mais au pair responsable de cette partie de l espace. Cela permet de bénéficier des mécanismes de tolérance aux pannes du système formé par les super-pairs à la fois pour les connexions avec les habitats et les connexions avec les centres de calcul. Figure 5.3 Organisation de notre système P2P avec un espace métrique à deux dimensions basées sur la localisation géographique des habitats. Les super-pairs du systèmes qui composent le bus de services par des liens courts en noir et des liens longs en rouge. Les points verts sur l espace métrique qui sont reliés au centres de calculs correspondent aux coordonnées de leurs connexions dans l espace métrique. En effet, chaque serveur du bus de services reçoit la responsabilité de gérer une partie de l espace métrique et donc de l ensemble des habitats et des connexions aux centres de calculs qui s y trouve. Avec cette structure, notre système permet de gérer, la diffusion de requêtes issues des centres de calcul sur des ensembles d habitats partageant des propriétés communes. Ces ensembles pouvant être formé par tous les habitats possédants les propriétés définies ou un nombre prédéfini d habitats les plus similaires d un habitat de 114

131 5.4. Validation du système proposé référence donnée. Pour gérer les souscriptions des centres de calculs à des informations issues des habitats, chaque habitat maintient une liste qui associe à chaque type d informations produites un ou plusieurs identifiants de centres de calculs ayant souscrit à cette information. Ainsi, un habitat envoie une information au bus de services, les serveurs la retransmettent jusqu au serveur responsable de la connexion choisie qui l envoie alors au centre de calcul correspondant. Les pannes sont gérés comme dans une DHT [66] par la redistribution des responsabilité de l espace métrique entre les voisins du pair qui a quitté le système. Ainsi, chaque habitat et centre de calcul doit maintenir les informations nécessaire pour contacter les voisins du super-pair qui est responsable d eux. La transmission des messages au niveau du bus de services se fait en au plus O(log 2 (n)) retransmissions, avec n le nombre de serveurs qui composent le bus. De même, les transmissions de messages par les habitats sont limitées uniquement aux communications avec le bus de services, sans nécessiter de retransmissions de leur part. 5.4 Validation du système proposé Pour valider notre grille d analyse, il est nécessaire de montrer que le système que nous avons défini en l utilisant est viable, mais qu il propose aussi un compromis qui correspond aux besoins exprimés par le projet. Ainsi, dans cette section, nous comparons qualitativement trois approches de système de fournisseur de services à l habitat : une approche centralisé pour servir de référence ; une approche basée sur la distribution du bus de services au niveau des habitats des clients ; l approche que nous avons retenue basée sur la distribution du bus de services sur un réseau de serveurs maintenu par le fournisseur de service. L approche centralisée est celle principalement utilisée par les fournisseurs de services actuels et constitue donc la référence en termes de performances. L approche basée sur la distribution du bus de services au niveau des habitats est une approche possible que nous avons écartée à cause de la quantité de messages issus des habitats qu elle induisait que nous avons jugés trop importante. Il est donc intéressant de comparer ses performances avec l approche de référence et celle que nous avons retenue en utilisant notre modèle. Nous comparons ces trois approches en fonction de quatre propriétés : le support du passage à l échelle ; la tolérance aux pannes ; la latence des transmissions ; la quantité de messages transmis par les habitats. 115

132 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat Ces propriétés couvrent l ensemble des contraintes non fonctionnelles qui ont été définies dans le projet. Les contraintes fonctionnelles n ont pas été considérées dans cette étude, car l ensemble des approches étudiées y répondait Support du passage à l échelle Dans cette étude, le support du passage à l échelle correspond à la capacité du bus de services à supporter l augmentation du nombre d habitats à gérer, mais aussi du nombre de centres de calcul auxquels il est connecté. Pour ce faire, nous allons considérer qu à chaque habitat et chaque centre de calcul, correspond un coût pour le bus de services. Ce coût représente la quantité de ressources, comme le nombre de cycles processeurs, d espace mémoire et de bande passante, nécessaires au système pour prendre en charge un habitat ou un centre de calcul. Dans une approche basée sur un système de gestion des habitats composé de serveurs hébergés par le fournisseur de services, les ressources sont limitées par le nombre de serveurs utilisés. Il faut donc que ce nombre croisse proportionnellement au nombre de passerelles résidentielles et de centres de calcul pour que le système puisse fonctionner. Ce modèle passe donc l échelle tant que l on rajoute des serveurs au niveau du système de gestion des habitats. Dans une approche basée sur un bus de services distribué sur les habitats, les ressources sont proportionnelles au nombre d habitats gérés par le système. Pour que le système fonctionne, il est donc nécessaire que les ressources présentes dans un habitat soient supérieures au coût que représente le fonctionnement du bus de services. En effet, ce sont ces ressources restantes qui permettent au système de gérer les centres de calculs. Ainsi, le nombre de centres de calculs peut, au maximum, croître proportionnellement avec le nombre d habitats. Le bus de services de cette approche supporte donc parfaitement l augmentation du nombre d habitats à gérer, mais impose des limites quant à l augmentation du nombre de centres de calculs. Enfin, dans l approche centralisée, on considère que le bus de services est géré par un serveur unique dont la quantité de ressources disponible est bornée. Ainsi, le système fonctionne tant que le coût cumulé par les habitats et les centres de calculs reste inférieur aux ressources disponibles. Ainsi, si le nombre d habitats ou/et de centres de calculs augmente, la quantité de ressources nécessaires pour les gérer peut dépasser les capacités du serveur. Cette approche ne peut donc pas supporter le passage à l échelle Tolérance aux pannes De la même façon que pour le passage à l échelle, nous déterminons le comportement du système par rapport aux pannes de ses composants. Plus particulièrement, nous allons déterminer pour chaque approche à partir de combien de pannes simultanées le bus de 116

133 5.4. Validation du système proposé services devient indisponible. Ainsi, nous considérons dans cette étude que le système devient indisponible quand les ressources à sa disposition deviennent insuffisantes pour gérer les habitats et les centres de calculs qui y sont connectés Pour l approche centralisée, la panne du serveur implique automatiquement l indisponibilité du bus. En effet, toutes les ressources y étant centralisées, si celui-ci devient indisponible, le bus de services n a alors plus aucune ressource pour fonctionner. L approche basée sur un bus de services distribué sur les habitats, le fonctionnement du bus de services est conditionné par le nombre d habitats connectés. Il faut donc, pour que le système continue de fonctionner, que la quantité de ressources mise en partage par les habitats reste suffisante pour gérer les centres de calcul. Ainsi, plus il y a d habitats pour fournir des ressources au système, plus la tolérance aux pannes de celui-ci est élevée. Pour notre approche basée sur un bus de services composés de serveurs hébergés par le fournisseur de services, des pannes au niveau des serveurs impliquent une diminution de la quantité de ressources disponible. Ainsi, le système continue de fonctionner tant qu il reste assez de serveurs pour fournir les ressources nécessaires à la gestion des habitats et des centres de calculs. En revanche, on constate que la tolérance aux pannes de ce modèle est d autant plus grande que la quantité de ressources que représente chaque serveur est faible. Il est donc préférable, pour tolérer les pannes, d avoir un grand nombre de serveurs possédants des ressources limités plutôt que peu de serveurs très performants Latence des communications Pour comparer la latence de ces trois approches, nous considérons le cas de la recherche, par un centre de calcul, des informations d état d un habitat donnée connecté au système. Nous approximons la latence pour que la recherche aboutisse en estimant le nombre de retransmissions nécessaires pour que la requête atteigne l habitat ciblé. Dans le cas d une approche centralisée, tous les habitats sont connectés au serveur hébergeant le bus de services. Ainsi, pour que la requête aboutisse, il ne faut qu une seule retransmission de la requête, quel que soit l habitat ciblé, ce qui correspond au cas optimal. L approche basée sur un bus de services distribué au niveau des habitats utilise un système similaire à SWAM [19], SCAN [153] ou RCAN [31] pour retrouver un habitat dans le système. Ce type de système résolvent les requête en O(log 2 (n)) retransmissions, avec n égal au nombre d habitats connectés au système. Ainsi, plus le nombre de clients du système augmente, plus la latence du système devient importante. Enfin, notre approche basée sur un bus de services hébergé par le fournisseur utilise le même type mécanisme de transmission des messages que dans l approche précédente. Ainsi, il faut O(log 2 (n)) retransmissions, pour que le message atteigne l habitat ciblé, avec cette fois n égal au nombre de serveurs qui composent le bus de services. Ce nombre est très inférieur au nombre d habitats connectés au système, même s il est dépendant de capacités de traitements des serveurs. En effet, moins les serveurs seront puissants, 117

134 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat plus leur nombre devra être important. Ainsi, il est possible de diminuer la latence des communications en utilisant un nombre plus faible de serveurs, mais plus puissant Quantité de messages transmis par les habitats Afin que le système fonctionne, les habitats doivent communiquer avec les centres de calculs, ce qui implique des échanges de messages. Or, les connexions des habitats pouvant être payantes pour le fournisseur de services, comme dans le cas de connexion GPRS ou UMTS, il est important que le système permette de limiter la quantité des messages transmis par les habitats. Pour représenter cette quantité de messages nous considérons le nombre de messages transmis par les habitats pour la réalisation d une requête ainsi que le nombre de connexions devant être maintenues par les habitats. Dans une approche centralisée, une connexion est nécessaire entre un habitat et le bus de services. De même, un seul message est nécessaire effectuer une recherche. C est donc l approche qui nécessite le moins de communications entre les habitats et le bus de services. Pour une approche basée sur un bus de services distribué au niveau des habitats, chacun de ces habitats doit maintenir m connexions avec d autres habitats présents dans le système pour former l overlay qui héberge le bus de services. De plus, pour répondre à une requête, cette approche nécessite O(log 2 (n)) retransmissions, avec n égal au nombre d habitats connectés au système. Ainsi, le nombre de messages transmis par les habitats est très élevé dans cette approche. Dans notre approche, chaque pair est connecté à un nombre k de serveurs composant le bus de services afin d optimiser la tolérance aux pannes au niveau des communications entre les habitats et le bus de services. En revanche, comme dans une approche centralisée, un seul message entre les habitats et le bus de services est nécessaire pour résoudre une requête. Ainsi, bien que le nombre de messages transmis par les habitats soit plus élevé que pour une approche centralisée, il reste très faible Bilan de la comparaison En comparant une approche centralisée avec les deux autres approches, nous constatons que la distribution du bus de services que ce soit sur les habitats ou sur un réseau de serveurs permet bien d améliorer le support du passage à l échelle et la tolérance aux pannes par rapport à un modèle centralisé. Cependant, elles impliquent toutes deux une augmentation de la latence des communications ainsi que du nombre de messages transmis par les habitats. Ainsi, chacune de ces trois approches représente un compromis différent pour le fournisseur de services (Tableau 5.8). Pour pouvoir fonctionner, l approche centralisée nécessite d être dimensionnée pour un nombre prédéfini d habitats et de mettre en place des mécanismes pour pallier aux pannes du serveur. Bien que cette approche permette de limite la latence dans les transmissions 118

135 5.5. Conclusion ainsi que la quantité de messages échangés, elle ne permet pas de répondre aux deux principaux besoins définies dans le projet que sont la tolérance aux pannes et la capacité de passage à l échelle. Ainsi, seules notre approches et celle basée sur un bus de services distribué au niveau des habitats permet de répondre aux besoins architecturaux du projet. Cela s explique par le fait que notre grille d analyse nous à permis de dégager ces deux approches comme des compromis possibles pour répondre aux besoins définis par le projet. En revanche, on constate que notre approches est possèdent des performances plus équilibrées dans le sens où elle implique une latence et une quantité de messages échangés par les pairs plus faible, même si elle est légèrement moins tolérante aux pannes. Table 5.8 Comparaison des performances obtenues par les trois approches considérées Centralisé Distribué sur les habitats Distribué sur un réseau de serveurs Passage à + + l échelle Tolérance aux ++ + pannes Latence ++ + Quantité de ++ + messages 5.5 Conclusion L utilisation de notre grille d analyse nous a permis de proposer un nouveau type de système P2P pour répondre aux besoins d un fournisseur de services à l habitat. En effet, aucun système existant ne permettait de réponde à l intégralité des besoins exprimés. Or notre grille d analyse a permis de dégager une solution basée sur des mécanismes similaires à ceux de systèmes comme SWAM [19], SCAN [153] ou RCAN [31] qui sont initialement des systèmes de recherche d informations. Le choix d utiliser ce type de mécanisme nous a permis de fournir plus de fonctionnalités que les systèmes de multicast applicatif existants en autorisant la diffusion de messages à des groupes d habitats partageant des propriétés communes plutôt qu à des groupes prédéfinis tout en limitant le nombre de messages échangés nécessaire. L étude du cas d un fournisseur de services à l habitat met donc en évidence qu il est possible de développer des systèmes plus adaptés que ceux existants en exploitant des mécanismes initialement créés pour d autres domaines applicatifs. Cela confirme donc notre postula initial qu une classification plus précise, basée sur les fonctionnalités développées depuis douze ans dans l ensemble des domaines applicatifs associés aux systèmes P2P 119

136 Chapitre 5. Proposition d un système P2P pour un fournisseur de services à l habitat permet de dégager de nouvelles approches plus adaptées que celles de la littérature pour répondre à un problème donné. 120

137 CHAPITRE 6 PROPOSITION D UN SYSTÈME P2P POUR LES ARCHIVES SCIENTIFIQUES Comme dans le chapitre précédent, nous présentons ici notre démarche pour proposer un système P2P adapté à l étude sur les archives scientifiques effectué dans le cadre d un projet régional de recherche. Notre objectif est d éprouver la validité de notre démarche sur un deuxième cas d étude très différent du premier afin de valider sa pertinence. Dans un premier temps, les besoins généraux d une archive scientifique et plus particulièrement d un cahier de laboratoire numérique sont définis à partir de nos constats sur les limites des offres existantes dans le domaine. À partir de ces besoins, nous effectuons une étude sur l adéquation des systèmes P2P qui ont été spécifiquement développés pour répondre à ces problématiques afin de déterminer les mécanismes développés dans la littérature pouvant être utilisés par notre système. Nous analysons une nouvelle fois les besoins du système au regard de cet état de l art pour dégager les propriétés du système que l on souhaite créer pour les utiliser en entrées de notre grille d analyse. À partir des approches dégagées par notre grille d analyse pour les trois couches fonctionnelles, le système complet est présenté puis comparé avec d autres approches pour analyser ses performances. 6.1 Besoins définis dans le cadre du projet sur les cahiers de laboratoire numérique L objectif du projet régional est de proposer un nouveau type cahier de laboratoire numérique plus centrer sur les besoins des chercheurs. Pour ce faire, nous proposons d utiliser le modèle P2P qui nous semble le plus adapter pour répondre à la fois aux besoins de l archivage scientifique et des utilisateurs. En effet, si les cahiers de laboratoire existants [138] 121

138 Chapitre 6. Proposition d un système P2P pour les archives scientifiques répondent aux problématiques d archivage, ils ne considèrent pas les enjeux de conservation des pratiques de travail pourtant indispensables à l adoption d un tel outil. De plus, l archivage n est perçu que sous l aspect de la curation, où l ensemble des documents est hébergé et maintenu par l organisme de tutelle du chercheur. Cette approche correspond donc à un point de vue institutionnel du problème car l entreprise possède généralement les droits sur les découvertes de ses employés et non à celui des utilisateurs d un cahier de laboratoire qui sert d outil d aide à la mémoire du chercheur [167]. Enfin, il nous semble particulièrement important qu un cahier de laboratoire numérique soit plus qu une simple transposition du concept papier au format numérique. En effet, l adoption du format numérique permet d ajouter de nouvelles fonctionnalités associées aux pratiques de travail des utilisateurs comme du partage de documents ou de la coécriture. De plus, le but du système n est pas de limiter cette collaboration au cadre exclusif des groupes de travail, mais au contraire de permettre la collaboration à l échelle de l ensemble des utilisateurs du système comme pourrait le permettre un réseau social académique 26. Nous avons donc défini quatre besoins majeurs auxquels devrait répondre un cahier de laboratoire numérique : la préservation des documents, la gestion des révisions, la recherche documentaire et la préservation des pratiques de travail Préservation des documents Le premier objectif d un cahier de laboratoire numérique est de conserver des traces du travail des chercheurs. Ainsi, l enjeu majeur d un tel outil est la préservation des documents produits et d en assurer l intégrité. En suivant la théorie des trois âges [128], un document doit pouvoir être consulté jusqu à la fin de sa durée d utilité administrative, voire pour des périodes encore plus longues si le travail se révèle d importance historique. Ainsi, un cahier de laboratoire numérique doit garantir l intégrité et l accessibilité des documents sur des périodes de plusieurs années. Pour ce faire, notre système doit répondre à trois risques : les pannes matérielles ; l obsolescence des formats numériques ; l obsolescence des technologies de stockage. La tolérance aux pannes matérielles implique qu une ou plusieurs pannes simultanées ne remettent pas en cause l intégrité et l accessibilité des documents pris en charge par le système. De même, pour prendre en charge l obsolescence des formats numériques, il faut garantir qu un document pourra être lu pendant toute la durée d utilité administrative, voire plus longtemps dans le cadre d archives définitives. Enfin, la prise en charge de l obsolescence des technologies de stockage est plus complexe, car elle nécessite que le 26. Academia.edu - Share Research, 122

139 6.1. Besoins définis dans le cadre du projet sur les cahiers de laboratoire numérique système puisse fonctionner avec des supports de stockage hétérogènes dont la nature doit pouvoir évoluer avec le temps Système de gestion de révision Le cahier de laboratoire suit le double objectif d aide à la mémoire du chercheur aussi bien que de preuve légale. Ainsi, ce cahier doit pouvoir refléter l ensemble du cheminement parcouru par le chercheur au cours de son travail tout en garantissant l exactitude des informations qui y sont consignées. Les systèmes de gestion de révision répondent à ce double objectif en enregistrant les traces de chaque révision faites sur un document tout en garantissant leur intégrité. De même, ces systèmes organisent les révisions selon leur ordre chronologique et logique, retraçant l historique complet de l écriture d un document. Enfin, ces systèmes permettent la coécriture de documents de façon sûre. En effet, si plusieurs utilisateurs peuvent modifier un même document, l ensemble des versions ainsi que leur auteur sera enregistré par le système. Cette fonctionnalité permet donc de servir de base à un système de coécriture de document, ce qui est la base du travail de recherche Recherche documentaire Comme toutes les archives, le cahier de laboratoire numérique doit répondre à la double contrainte de préservation et d accessibilité des documents. Il est donc nécessaire pour le système de permettre aux utilisateurs de rechercher les documents qui y sont référencés. Le cahier de laboratoire est un cas assez particulier d archive dans le sens où les politiques d accessibilité des documents qui le composent sont hétérogènes. En effet, une partie du travail référencé est composée de données personnelles du chercheur, alors que d autres sont réservées exclusivement aux membres d une même équipe projet ou sont éventuellement publiques. Cette particularité doit être prise en considération dans la recherche documentaire afin de ne laisser transparaître que les informations nécessaires. Ainsi, certains documents même s ils ne sont pas accessibles en lecture doivent pouvoir être trouvés au cours d une recherche alors que d autres ne doivent pas apparaître du tout. Enfin, la fonctionnalité de recherche documentaire peut être utilisée par plusieurs acteurs différents. En effet, celle-ci ne se limite pas aux recherches effectuées par les chercheurs ainsi qu au partage de connaissance entre les communautés de recherche. Ainsi, les services administratifs, comme les services de valorisation ou les services juridiques des institutions de rattachement peuvent avoir besoin de retrouver des documents consignés dans les cahiers de laboratoire des chercheurs 27. Le système de recherche doit donc pouvoir répondre aux besoins de l ensemble des acteurs impliqués dans les activités liées à la recherche. 27. CNRS : Petit guide pour la gestion du cahier de laboratoire national ; mpr/pratique/guides/cln/cln_guide-gestion.pdf 123

140 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Conservation des pratiques de travail L adoption d un outil est fortement liée aux modifications des pratiques de travail que celui-ci induit pour les utilisateurs. C est justement l un des principaux freins à l adoption du cahier de laboratoire classique dans les domaines où leur utilisation n est pas traditionnelle [167]. Aujourd hui, chaque utilisateur possède ses propres pratiques et ses propres outils pour créer/consulter/modifier/organiser ses documents numériques. Proposer un outil unifié qui regrouperait l ensemble de ses fonctions demanderait donc aux utilisateurs de modifier l ensemble de leurs pratiques de travail. Cette constatation peut expliquer le relatif échec des solutions commerciales existantes, car elles imposent une forte modification de leurs pratiques de travail sans offrir un gain personnel suffisant [138]. Il est alors nécessaire que notre solution permette à l utilisateur de conserver ses propres pratiques de travail tout en offrant les fonctionnalités d un cahier de laboratoire numérique pour que notre solution soit adoptée par les utilisateurs. Ainsi, notre système doit être agnostique concernant le format des documents afin de laisser aux utilisateurs le libre choix de leurs outils de création/modification/consultation des documents. 6.2 Étude des systèmes P2P existants répondant aux besoins du projet Il existe trois grandes catégories de systèmes P2P qui peuvent répondre au moins partiellement aux besoins que nous avons définis. Les premiers sont les systèmes de stockage sûr tels que Oceanstore [26]. En effet, ces systèmes répondent directement à la problématique de préservation des documents numériques. De même, la recherche documentaire sur les systèmes P2P est un domaine de recherche à part entière et de nombre systèmes ont donc été proposés pour répondre spécifiquement à ce besoin. Enfin, les systèmes P2P de travail collaboratif et de gestion des communautés permettent de répondre aux besoins associés aux partages de documents au sein des groupes de projet et à la coécriture. Par manque de place, seul un résumé de cette étude sera présenté ici, l étude complète des différents types de systèmes sera présenté en annexe Systèmes P2P de stockage sûr Les systèmes de stockage sûr en P2P reposent tous sur le modèle Intermemory [38]. Le principe de ce modèle est d utiliser un code à effacement pour encoder les documents de sorte que même si une ou plusieurs parties d un document sont perdues, il est toujours possible de le reconstruire à partir des parties restantes. Les documents ainsi encodés sont donc fragmentés puis distribués entre les pairs de sorte à réduire les risques de pannes corrélés (Fig. 6.1). Chaque système P2P basé sur ce modèle représente un cas d utilisation particulier 124

141 6.2. Étude des systèmes P2P existants répondant aux besoins du projet Figure 6.1 Encodage et distribution des documents selon le modèle d Intermemory (Tabl. 6.1). Ainsi, OceanStore [26] présente un système complet reposant sur un réseau de serveur afin prendre en charge les besoins de préservation des archivages courant et semi-courant. Glacier [71], qui repose-lui aussi sur un réseau de serveur, se spécialise dans les besoins des archivages semi-courant et définitifs. Enfin, Total Recall citetotalrecall propose un système de préservation correspondant à un archivage semi-courant qui repose sur les machines des utilisateurs. La principale limite de ces systèmes est qu ils ne prennent pas en compte les fonctionnalités de recherche documentaire qui sont nécessaire à un système d archive. En effet, le mécanisme de recherche sur ces systèmes se limite à une recherche par identifiant, ce qui n est pas suffisant pour répondre à l ensemble de nos besoins Système P2P de recherche documentaire Il existe de très nombreux systèmes de recherche documentaire basés sur le modèle P2P. On peut distinguer deux grandes catégories d approches : les systèmes de recherche par mots-clef et les systèmes de recherche par similarités. Les systèmes de recherche par mots-clefs reposent sur un fichier inversé qui lie des documents à des mots-clefs. Les performances des systèmes P2P de recherche par mots-clefs dépendent principalement de l approche de distribution du fichier inversé sur le système. Les deux approches existantes [178] sont celles par documents et celles par termes. Dans le premier cas on associe chaque document aux mots-clefs auxquels ils sont liés puis 125

142 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Machines des clients Cou- Semi rantes Table 6.1 Comparaison des systèmes de stockage sûr Systèmes Type de pairs Type d archives Integrité Modèle de redondance Documents modifiable OceanStore Serveurs Courantes Tolérance Code à effacement et Oui et Semi aux réplication Courantes pannes byzantines Glacier Serveurs Semi Courantes Tolérance Code à effacement Non aux pannes byzantines Re- Total call Tolérance aux pannes simples Code à effacement Non on distribue ces documents entre les pairs. À l inverse, dans une approche par termes, on associe chaque mot-clef aux documents auxquels ils sont liés, puis on distribue la responsabilité des mots-clefs entre les pairs. Un autre facteur pouvant impacter un système de recherche par mots-clefs est le mécanisme d attribution de ces mots-clefs. En effet, l automatisation de l attribution des mots-clefs, par exemple par une fouille de texte, limitera la capacité de recherche du système à des documents textuels [49, 178]. À l inverse, une attribution des mots-clefs par les utilisateurs, comme dans une folksonomie [70] ou basée sur une ontologie [147, 17], permettra de gérer n importe quel type de documents, mais autorisera pas certains types de recherches, comme la recherche plein texte. Ainsi, chacune des compositions d approches permet représente un compromis différent qui n est applicable que dans certains contextes (Tabl. 6.2). Les systèmes de recherche par similarité reposent sur la création d un espace métrique dans lequel est classé chacun des documents du système. Chaque document est évalué en fonction d un nombre donné de métriques qui correspond à ses coordonnées dans l espace métrique. Ainsi, quand une recherche est effectuée, l utilisateur doit définir les coordonnées d un point de l espace pour obtenir les documents qui sont les plus proches de ce point. Comme pour les systèmes P2P de recherche par mots-clefs, les différences de performances entre les systèmes P2P de recherche par similarité dépendent de l approche utilisée pour distribuer l espace métrique entre les pairs (Tabl. 6.3). Pour ce faire on distingue deux types d approches : la réduction de l espace métrique et la navigation dans cet espace. La première consiste à utiliser un algorithme [81] pour réduire le nombre de dimensions de l espace métrique à une seule et ainsi le distribuer facilement entre les pairs [145, 125, 54]. Dans la deuxième approche, l espace métrique est découpé en zones de responsabilité, chaque zone est ensuite attribuée à un pair du système. Les pairs créent ensuite des 126

143 6.2. Étude des systèmes P2P existants répondant aux besoins du projet Table 6.2 Comparaison des systèmes de recherche documentaire par mots-clefs avec N le nombre de pairs, R le nombre de termes présent dans la requête, T D le nombre moyen de termes par documents et D T le nombre moyen de documents par terme Distribution Description Quantité de Calculs nécessairecation Domaine d appli- des documents messages échangé Par document Humaine O(N) O( T D N ) Tout type de documents Par document Automatique O(N) O( T D N ) Document textuel Par terme Humaine O(R) O((D T ) R ) Tout type de documents Par terme Automatique O(R) O((D T ) R ) Document textuel liens entre eux, afin de former un overlay structuré pour router les requêtes jusqu au pair responsable de la zone de l espace métrique ciblé [19, 153, 31] (Fig. 6.2). La principale limite des approches par similarité est qu elles ne peuvent supporter que des ensembles de documents pour lesquels il est possible de trouver des propriétés communes afin de pouvoir déterminer leurs coordonnées dans l espace métrique. Figure 6.2 Résolution d une recherche de zone par un système P2P reposant sur la navigation dans un espace métrique Systèmes P2P de travail collaboratif Les principaux systèmes de travail collaboratif basés sur le modèle P2P sont les systèmes P2P privés et les systèmes d ami à ami (Friend-to-Friend ou F2F). La principale différence entre ces deux approches est le cloisonnement des informations sur les pairs 127

144 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Table 6.3 Comparaison des systèmes de recherche documentaire par similarité Distribution Expressivité Tolérance à l attrition Equilibrage de la charge Domaine d application Réduction Limité (300 dimensionsment Faible Oui Type de docu- d espace ciblé Navigation Limité (10 dimensionsment Bonne Non Type de docu- dans l espace ciblé dans le système [134]. Ces systèmes offrent un certain nombre de fonctionnalités de bases pour supporter le travail collaboratif comme du partage de fichiers, des forums, des chat rooms, une messagerie instantanée ou encore un système de messagerie normal [134]. Leur principale particularité est d offrir un niveau de confidentialité très élevé. En effet, ces systèmes sont presque indétectables et totalement opaques pour quelqu un qui lui est extérieur [129]. En marge des systèmes P2P, on trouve les systèmes de gestion de révision décentralisés comme Git 28 ou Mercurial 29 qui peuvent fonctionner de façon Ad-Hoc. Ainsi, si ces systèmes peuvent supporter un fonctionnement décentralisé, ils n offrent aucune fonctionnalité pour la formation de systèmes P2P entre les utilisateurs. En fonctionnement décentralisé, ces systèmes ne sont donc adaptés que pour des groupes de deux ou trois utilisateurs Analyse de l adéquation des systèmes existants par rapport au cas d étude Contrairement au cas d étude précédent en 5.3, la littérature propose de nombreuses approches pouvant directement être réutilisées par notre système. Ainsi, le modèle de stockage d Intermemory [38] semble être la solution la plus adaptée pour de l archivage de longue durée, comme les archives semi-courantes ou définitives. De même, les systèmes de gestion de révisions décentralisés répondent au moins partiellement à nos besoins si la propagation des révisions est automatisée entre les membres d un même groupe de travail. Enfin, les systèmes P2P privés ou F2F répondent aussi à nos besoins de collaboration et de confidentialité des documents. Le besoin le moins bien couvert par l existant correspond à la recherche documentaire. En effet, même si de très nombreux systèmes ont déjà été proposés, leurs performances ne nous semblent pas être suffisamment satisfaisantes pour être utilisées en l état [166]. Ce dernier point nécessitera donc l adaptation des modèles proposés dans la littérature afin de répondre à nos besoins particuliers. 28. Git, the fast version control system, Mercurial, 128

145 6.3. Proposition du système 6.3 Proposition du système Pour utiliser notre grille et ainsi déterminer le système P2P le plus adapté à un cahier de laboratoire numérique, nous analysons les besoins dégagés en 6.1 afin de déterminer les propriétés qui devront être prises en compte. À partir de cet ensemble de propriétés, nous utilisons notre grille d analyse pour déterminer les approches les plus efficaces au niveau des couches application, indexation et adaptation du réseau hôte du système. Une fois toutes les approches choisies, elles sont assemblées afin de présenter une vue d ensemble du système final Définition des propriétés et contraintes à considérer Comme dans le cas d étude précédant, nous analysons les besoins d un cahier de laboratoire numérique au regard de l étude précédent de l existant afin de définir les propriétés et contraintes qui seront utilisées en entrées de notre grille d analyse. À partir des besoins, nous avons donc dégagé quatre ensembles de propriétés : une architecture adaptée à l organisation du travail des utilisateurs ; la gestion de tout les types documents ; la sécurité du système ; le partage documentaire. Les deux premiers correspondent à la division du besoin de conservation des pratiques de travail. En effet, ce besoin peut se découper en deux ensembles de propriétés non fonctionnelles, l une portant sur l architecture du système et l autre sur la nature des documents devant être pris en charge. À l inverse, nous avons regroupé le besoin de gestion de version et de préservation des documents dans la sécurité du système. En effet, ces deux besoins sont associés à de l intégrité et de l imputabilité qui sont des composantes de la sécurité [5]. De même, dans le cadre du besoin de recherche documentaire, on retrouve des notions de confidentialité qui sont aussi de l ordre de la sécurité du système. Enfin, le partage documentaire regroupe l ensemble des propriétés associées aux principaux besoins fonctionnels du système Architecture adaptée à l organisation du travail des utilisateurs L un des objectifs du système est d exploiter la souplesse d organisation du modèle P2P pour corréler l architecture du système avec l organisation des groupes de travail des utilisateurs. En effet, avec les évolutions du travail scientifique, les chercheurs travaillent de plus en plus en groupes associés à des projets. Ainsi, notre objectif est que notre système reflète cette organisation de sorte que chaque utilisateur soit représenté par un pair et que ce pair soit relié à l ensemble des pairs des utilisateurs avec qui il travaille. L idée sous-jacente de cette approche est d adapter automatiquement le système aux relations 129

146 Chapitre 6. Proposition d un système P2P pour les archives scientifiques de travail entre les utilisateurs afin de préserver le plus possible les pratiques de travail de ces derniers. Ainsi, notre système doit reposer sur un overlay dont les liens entre les pairs doivent être corrélés avec les relations de travail qu entretiennent les utilisateurs du cahier de laboratoire Gestion de tout type de document Dans le bus de permettre aux utilisateurs de conserver leurs pratiques, il est nécessaire que notre système puisse gérer n importe quel type de format de documents. En effet, pour faciliter l adoption du système par les utilisateurs, il est important qu ils puissent conserver les outils qu ils utilisent habituellement pour créer, éditer et lire leurs documents numériques. Le système ne doit donc faire aucune supposition quant à la nature des documents qu il doit gérer. Ainsi, il n est pas possible de trouver des propriétés communes ou d utiliser un algorithme pour analyser les documents présents sur le système Sécurité du système Le système doit répondre à de fortes contraintes sur le domaine de la sécurité. En effet, les besoins qui ont été définis imposent des exigences relatives à trois des cinq types de contraintes de sécurité des systèmes distribués définies par l institut national des standards et technologies des États-Unis en 2004 [5], à savoir : l imputabilité, la confidentialité et l intégrité Imputabilité Dans [5], l imputabilité consiste à ce que toute action dans le système puisse être tracée jusqu à son initiateur. Cela implique donc la traçabilité de toute action ainsi que la non-répudiation de celle-ci. Notre système doit assurer l imputabilité de toutes modifications faite sur un document. En effet, le système doit garder la trace des auteurs de chacune des révisions qui ont été appliquées à un document donné Confidentialité Dans [5], la confidentialité consiste à prévenir la lecture, par une personne non autorisée, des données du système. La confidentialité d une donnée peut s appliquer à la fois sur les informations stockées dans le système, mais aussi durant la transmission et le traitement de celle-ci. Dans notre cas, chaque document pris en charge par le système ne doit pouvoir être lu ou même trouvé que par les personnes autorisées. En effet, la simple connaissance de l existence d un document par une personne non autorisée peut être considérée comme une infraction à la confidentialité de celui-ci. 130

147 6.3. Proposition du système Intégrité Dans [5], l intégrité couvre à la fois l intégrité des informations dans le système, mais aussi l intégrité du fonctionnement du système lui-même. Le but est d empêcher toute altération non autorisée d une donnée ou du fonctionnement du système. Notre système doit gérer plusieurs niveaux d intégrité des documents. En effet, il doit gérer l intégrité des révisions de chaque document, afin de répondre à son rôle d archive courante. De même, le système doit pouvoir assurer l intégrité à long terme de ces documents afin de répondre à son rôle d archive semi-courante. Enfin, la nature particulière d un cahier de laboratoire fait que chaque révision d un document peut être considérée comme faisant partie des documents à conserver dans une archive semi-courante. En revanche, nous ne considérons pas la préservation des moyens de lecture des documents. En effet, que ce soit l utilisation de formats de fichier normalisés pour l archivage, ou la virtualisation des environnements de travail, chacune de ces approches peut être supportée par un système P2P garantissant l intégrité des données. En effet, il est possible de réencoder un fichier dans le format adéquat quand il passe à un archivage semi-courant. De même, les machines virtuelles créées pour sauvegarder un environnement de travail peuvent être considérées comme des documents et donc enregistrées dans le système. Ainsi, tant que le système garantit l intégrité des documents, il est possible de garantir la lecture de ces derniers. Ainsi, le système doit assurer l intégrité à long terme de l ensemble des documents et de leurs révisions. Pour ce faire, cette intégrité doit pouvoir être périodiquement vérifiée et les documents reconstruits si celle-ci risque d être compromise Le partage documentaire Le partage documentaire est le principal besoin fonctionnel de notre système. En effet, il regroupe aussi bien la réplication des documents partagés par les membres d un même projet que la capacité de recherche de nouveaux documents sur l ensemble du système. On distingue deux types de partage : un partage proactif des documents au sein d un même groupe projet où les membres doivent être avertis de l ajout de nouveaux documents ou révisions ; la recherche de documents sur le système en dehors des groupes de projet ; le stockage sûr des documents. Dans le premier cas, l ensemble des nouveaux documents ou révisions d un projet doit être diffusé à tous les membres de ce projet. Dans le deuxième cas, chaque utilisateur doit pouvoir retrouver sur le système les documents ou informations sur les documents pour lesquels il possède un droit d accès. Ainsi, pour une requête donnée, un utilisateur doit recevoir la liste des informations sur l ensemble des documents dont il a le droit de connaitre l existence. 131

148 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Enfin, comme nous l avons montré dans la section 6.3.1, l approche la plus efficace pour assurer le stockage sûr des documents est le modèle d Intermemory [38]. Ce modèle repose la fragmentation des documents et la distribution de ces derniers sur les pairs présents dans le système. Ainsi, il est nécessaire d envoyer les fragments d un document sur plusieurs pairs pour le stocker et de récupérer au moins une partie de ses fragments pour pouvoir le lire Utilisation de notre grille d analyse Nous utilisons ici notre grille d analyse afin de déterminer les approches les plus adaptées pour composer notre système P2P de cahier de laboratoire numérique. Ainsi, nous utilisons l ensemble des propriétés et des contraintes que nous venons de dégager comme entrées pour notre grille pour déterminer quelle approche doit être utilisée au niveau de chacune des trois couches fonctionnelles du système. Enfin, nous présentons une vue d ensemble du système afin d expliciter les interactions entre les différentes approches utilisées au niveau de chacune des couches Couche application Trois objectifs influent sur les approches à retenir au niveau de la couche application : la diffusion de données à l ensemble des membres d un même groupe d utilisateurs ; la recherche de documents sur l ensemble du système ; la prise en charge des échanges de données nécessaires à l Intermemory [38]. Pour le premier cas, les membres d un groupe d utilisateurs sont définis au moment de l envoi des données composant un document. Il est donc possible d utiliser un modèle de diffusion de données pour répondre à ce besoin. En revanche, pour la recherche de documents, il est impossible de prévoir quel utilisateur aura besoin d un document avant qu il n en formule la demande. Ainsi, seul le modèle de collecte de données est applicable dans ce cas précis. Cette collecte se fait en deux étapes, la première consistant à renvoyer l ensemble des informations relatives aux documents répondant à la requête et la deuxième permettant de récupérer un document précis défini dans la requête Le troisième point est plus complexe à gérer. En effet, dans Intermemory, les documents sont fragmentés de sorte que seule une partie de l ensemble de ces fragments est nécessaire à la reconstruction du document original. Ainsi, pour stocker un document il faut envoyer ses fragments sur un ensemble de pairs pour qu ils les stockent. On peut considérer qu au moment de l envoi, cet ensemble de pairs est connu. En effet, ce dernier peut être déterminé par un algorithme comme une fonction de hachage [3] ou tout autre mécanisme permettant de créer un lien logique entre le document initial et les pairs responsables du stockage des fragments. De même, pour reconstruire un document, il est nécessaire de récupérer au 132

149 6.3. Proposition du système moins une partie des fragments de celui-ci. Ainsi, si la récupération des fragments est un mécanisme de collecte, car il n est pas possible pour les pairs les hébergeant de déterminer quand ils devront être récupérés, l envoi des requêtes peut être fait selon un mécanisme de diffusion. En effet, l ensemble des pairs qui hébergent des fragments d un même document est préalablement connu du l émetteur de la requête. Enfin, il est nécessaire que les pairs qui hébergent ces fragments vérifient périodiquement leur intégrité et informent les pairs responsables d un document si elle est compromise. Ainsi, l envoi des informations sur la compromission des fragments de document doit lui aussi être effectué par une diffusion de donnée. Ainsi, notre système doit implémenter au niveau de la couche d application les approches suivantes : la diffusion automatique des nouveaux documents et des révisions à l ensemble des membres d un même groupe projet ; la collecte des informations relatives aux documents répondant à une requête donnée ; la collecte d un document précis défini dans une requête ; la diffusion des fragments composant un document à un ensemble de pairs prédéfini ; la collecte des fragments d un document ; la diffusion de la requête de collecte des fragments d un document à l ensemble des pairs les hébergeant ; la diffusion des informations de compromission d intégrité des fragments de documents. Les couches suivantes devront considérer les besoins relatifs à chacune de ses approches et ainsi apporter les fonctionnalités nécessaires pour soutenir leur fonctionnement Couche d indexation Bien que le système doive répondre à de nombreux besoins de collectes et de diffusions de documents au niveau de la couche application, certains d entre eux peuvent être gérés directement au niveau de la couche d adaptation du réseau hôte. En effet, l organisation des pairs dans notre système, qui est de la responsabilité de la couche d adaptation du réseau hôte, devant suivre l organisation des groupes de projet, la gestion de ses groupes et donc la diffusion des messages à l ensemble de ses membres, peut être géré sans indexation. Ainsi, les propriétés et contraintes d indexation du système peuvent être divisés en deux catégories : les propriétés et contraintes d indexations liés à la recherche documentaire ; l indexation des documents présents sur l ensemble du système. 133

150 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Chacune de ses catégories est donc étudiée séparément. Les approches obtenues sont ensuite regroupées dans une synthèse afin de proposer une vue d ensemble des mécanismes développés au niveau de la couche d indexation Les propriétés de recherche documentaire Le système de recherche documentaire doit permettre de retourner la description et la référence des documents répondant aux critères de la requête. Notre système ne pouvant ne faire aucune supposition quant à la nature des documents qu il héberge, seule la recherche par mots-clefs définis manuellement peut être utilisée. En effet, il n est pas possible de définir des propriétés communes ou un mécanisme automatique d attribution de mots-clefs sans faire aucune supposition quant à la nature des documents. De plus, le système de recherche doit retourner des résultats complets afin de fournir aux utilisateurs des mécanismes évolués de recherche, comme la recherche à facettes [24]. Enfin ce mécanisme de recherche ne doit pas compromettre la confidentialité des informations relatives aux documents. En utilisant note grille d analyse (Tableau 6.4), on constate qu aucune approche ne permet de répondre à l intégralité des besoins exprimés. En effet, l approche la plus adaptée semble être l utilisation d un index global centralisé, mais cette approche va à l encontre du besoin de corrélation de l architecture du système avec l organisation des groupes de travail. De même, si la tolérance aux pannes et surtout le support du passage à l échelle ne sont pas des besoins exprimés explicitement par le projet, ils restent particulièrement désirables et ne peuvent être totalement négligés. En effet, l objectif du système n est pas d uniquement facilité le partage de documents au sein d un même groupe projet, mais aussi avec l ensemble de la communauté scientifique qui utiliserait le système. Cela exclut donc l utilisation d un index global répliqué, qui ne peut supporter qu un nombre d utilisateurs limité. De même, au vu de l état de l art sur la recherche par mots-clefs en , on constate qu aucune approche existante n est pleinement satisfaisante par rapport à nos besoins. Il est donc nécessaire d en proposer une nouvelle ou/et de relaxer certaines des contraintes. En effet, le besoin de confidentialité semble difficile à concilier avec les autres besoins. Or on peut supposer que la recherche de documents confidentiels est différente d une recherche sur l ensemble des documents présents dans le système et repose sur d autres postulats. En effet, un service juridique ou de valorisation d une institution donnée peut avoir besoin de rechercher des documents confidentiels des chercheurs appartenant à cette institution. La portée d une telle recherche est donc beaucoup plus limitée qu une recherche sur l ensemble du système. De même, tous les documents étant répliqués au sein d un même groupe projet, la recherche d un document confidentiel relatif à ce projet par un membre du groupe correspond alors à une simple recherche locale. Ainsi, il est préférable de dissocier la recherche de documents confidentiels de la recherche de documents sur l ensemble du système. Pour la recherche de documents confidentiels, si l on considère que la portée de cette recherche n implique qu un nombre de pairs limité, le tableau 6.4 indique soit une approche 134

151 6.3. Proposition du système Table 6.4 Performances des approches possibles au niveau de la couche d indexation Index global Index global Index locaux Index partagés index distribué index distribué centralismantiqumantique répliqué sans sé- avec sé- Passage à l échelle Tolérance aux pannes Recherche par motsclefs Compètude Faux négatif Confidentialité + ++ par index locaux soit par index répliqués. Le besoin prépondérant étant la confidentialité, les index locaux sont les plus adaptés. De plus, même si il n est pas possible de garantir la complétude des résultats avec ce type d approche, la réplication massive des documents entre les membres d un même groupe projet permet d approcher des performances des index partagés. La contrainte de confidentialité étant relaxée pour la recherche sur l ensemble du système, qui ne couvre plus que les documents publics, les approches les plus adaptées sont les index distribués sans sémantique et les index partagés. Chacune de ses approches correspond en fait à une méthode de distribution du fichier inversé reliant les mots-clefs aux documents, à savoir une approche par documents pour les index partagés et les approches par termes pour les index distribués. À partir du tableau 6.3 de notre état de l art, on peut en conclure qu aucune de ses approches ne permet de répondre totalement à nos besoins. En effet, les approches par documents nécessitent la diffusion d une requête à tous les pairs du système pour obtenir l ensemble des résultats, ce qui est beaucoup trop coûteux. De même, une approche par termes, bien que nécessitant de contacter moins de pairs, impose le calcul d une intersection de plusieurs listes, ce qui demande trop de ressources de calculs pour les pairs du système. Il est donc nécessaire de proposer une nouvelle méthode de distribution adaptée à notre contexte. Notre objectif est donc de définir une méthode de distribution d un fichier inversé permettant de limiter à la fois le nombre de messages échangés et la quantité de calculs nécessaire pour répondre à une recherche par mots-clefs retournant un résultat complet. Ces propriétés correspondant aux avantages cumulés des approches par documents et par termes, nous proposons donc une approche hybride de celle-ci. Ainsi, comme dans une 135

152 Chapitre 6. Proposition d un système P2P pour les archives scientifiques approche, par termes, chaque mot-clef est associé à une liste de documents afin de limiter le nombre de pairs devant être contactés pour répondre à une requête. Ensuite, comme dans une approche par documents, chaque document d une liste associée à un mot-clef est lui mêmes associées à l ensemble des mots-clefs qui y correspondent (Fig. 6.5). À partir de la liste des documents associés à un mot-clef donnée, il est donc possible de déterminer l ensemble des documents qui répondent à une requête composée de plusieurs mots-clefs. Figure 6.3 Structure de notre index pour la recherche par mots-clefs Une telle approche permet donc, sur un index distribué sans sémantique, de répondre à des requêtes composées de plusieurs mots-clefs sans nécessiter de calculs d intersection de liste. En revanche, l ajout d un document ou d un mot-clef à un document nécessite un mécanisme supplémentaire. En effet, l ajout d un nouveau mot-clef à un document implique que cet ajout doit être répercuté sur l ensemble des listes associées aux motsclefs attribués à ce document. De même, cet index ne permet pas de retrouver un document précis, mais seulement l ensemble des documents associés à tous les mots-clefs présents dans une requête. Ainsi, quand on ajoute un document au système, il n est pas possible de déterminer si ce document existe déjà dans le système à partir de cet index. Il faut donc qu il soit associé à un index de l ensemble des documents pour pouvoir être utilisé. Or notre système nécessite justement un tel index pour répondre aux besoins Les propriétés d indexation des documents Pour assurer les fonctionnalités du modèle d Intermemory [38] que nous voulons utiliser, il est nécessaire d indexer chaque document du système ainsi que chaque fragment qui composent ses documents. De plus, un index de l ensemble des documents pouvant être recherchés sur l ensemble du système est nécessaire pour soutenir notre index hybride présenté dans la section précédente. 136

153 6.3. Proposition du système L indexation des documents doit donc gérer deux types de ressources très différentes que sont les informations sur les documents et les fragments documentaires. Dans les deux cas, l approche d indexation doit permettre de retrouver la ressource exacte recherchée. En effet, cet index ne sert qu à la réalisation des fonctionnalités du système et non à une recherche humaine. Le système peut donc, dans les deux cas, fournir une description exacte de la ressource recherchée. À partir de notre grille d analyse (Tableau 6.5), l approche la plus adaptée est un index distribué sans sémantique. En effet, la confidentialité des informations sur les documents peut, dans ce cas particulier, être gérée directement par un mécanisme de chiffrement des informations relatives à un document confidentiel. Ainsi, seule une personne possédant la clef pour déchiffrer les données pourra lire les données obtenues. De même, le placement des fragments documentaire n étant soumis à aucune contrainte, l index distribué sans sémantique, permet le placement de ses fragments, ce que nous avons défini par le nomadisme des ressources dans la section Table 6.5 Types d approches associées aux besoins et contraintes dégages Index global Index global Index locaux Index partagés index distribué index distribué centralismantiqumantique répliqué sans sé- avec sé- Passage à l échelle Tolérance aux pannes Recherche exacte Confidentialité + ++ Nomadisme NA NA NA NA Coût de ++ + maintenance Ainsi, nous obtenons deux index distribués sans sémantique pour répondre à l ensemble des nos besoins d indexation des documents. Le premier index permet de renvoyer un ensemble d informations associées à un document donné. Ces informations correspondent à l ensemble des mots-clefs associé à ce document, les références de l ensemble des fragments documentaires utilisés pour le stockage sûr de ce document ainsi que les informations nécessaires pour contacter les pairs hébergeant ce document. Le deuxième index permet de retrouver un fragment de document à partir de sa référence. Il contient les informations nécessaires pour vérifier l intégrité de ce fragment ainsi que celles nécessaires pour contacter le ou les pairs responsables du document. En effet, ces informations sont 137

154 Chapitre 6. Proposition d un système P2P pour les archives scientifiques nécessaires afin que les pairs responsables d un document soient informés de l éventuelle compromission de l intégrité du fragment Synthèse La couche d indexation repose donc sur trois index distribués sans sémantique (Fig. 6.6) et d index locaux. Le premier index distribué sert à la recherche documentaire sur l ensemble du système. Cet index supporte la distribution du fichier inversé liant les documents aux mots-clefs qui le décrivent. Le deuxième index distribué sert au stockage des fragments de documents utilisé par le système de stockage sûr basé sur le modèle d Intermemory [38]. C est cet index qui va permettre au système de distribuer les fragments entre les pairs et de pouvoir les retrouver pour reformer le document initial. Enfin le troisième index distribué sert à soutenir le fonctionnement des deux précédents index en stockant les informations sur les documents eux-mêmes. Ainsi, cet index sert à la fois à référencer l ensemble des mots-clefs associés à un document donné, mais aussi la localisation de l ensemble des fragments qui le compose et les informations permettant de contacter les pairs qui hébergent des copies de ce document. Figure 6.4 L organisation et les interaction entre les trois index sans sémantique et un utilisateur. 138

155 6.3. Proposition du système L approche par index locaux est utilisée pour répondre au besoin de recherche de documents confidentiels. En effet, le mécanisme de recherche sur l ensemble du système ne prend en charge que les documents publics n ayant aucune contrainte de confidentialité. La portée d une recherche sur les index locaux est donc limitée aux documents des chercheurs faisant partie d un même groupe projet ou d une même institution. Cette limitation doit donc être prise en charge par la couche d adaptation du réseau hôte. Enfin, pour répondre au besoin de gestion de tous types de documents, nous utilisons un système d attribution de mots-clefs par les utilisateurs. Ce mécanisme doit être pris en compte au niveau de la couche application 30. Au vu de la structure de notre index hybride, l attribution d un nouveau mot-clef se fait préalablement sur l index distribué ayant la charge des documents présents dans le système. Une fois cet index mis à jour, l information est diffusée à l ensemble des pairs ayant la charge d un mot-clef associé à ce document. Cette diffusion n est possible que parce que le pair indexant le document maintient aussi la liste de l ensemble des mots-clefs auxquels il est associé Couche d adaptation du réseau hôte La couche d application doit répondre à quatre besoins : le système doit utiliser un overlay ; la construction de l overlay doit être guidée par les relations de travail entre les utilisateurs ; l overlay doit soutenir un index distribué sans sémantique ; l overlay doit soutenir les recherches sur des index locaux. Les deux premiers besoins sont liés au fait que l architecture du système doive suivre l organisation des relations de travail des utilisateurs. Ils impliquent donc l utilisation modèle semblable à un système d ami à ami (F2F) [134]. Ainsi, chaque utilisateur peut intégrer un autre utilisateur à un groupe de travail auquel il appartient en créant une connexion entre leurs deux pairs. Si un pair n entretient plus aucune connexion avec un autre membre du groupe, il est alors exclu de celui-ci. La gestion du groupe de travail se fait donc par les interactions sociales entre les utilisateurs et est directement répercutée sur la structure de l overlay. Cet overlay est utilisé pour assurer la diffusion des documents et révision au sein d un même groupe projet. Afin d assurer la confidentialité des échanges il est nécessaire que, comme dans un système P2P privé [134], les informations relatives aux membres du groupe soient aussi diffusées à l ensemble des pairs qui y appartiennent 31. La diffusion de ses informations est possible, car à l intégration d un nouveau membre 30. Bien que relevant de la couche application, nous expliquons ici le fonctionnement du mécanisme, car il est issu d une contrainte générée au niveau de la couche d indexation 31. Ce mécanisme relève de la couche application, mais n émerge qu après avoir choisi l utilisation d un modèle d ami à ami pour la création de l overlay 139

156 Chapitre 6. Proposition d un système P2P pour les archives scientifiques par un membre appartenant déjà à ce groupe, ce membre du groupe connait la liste de l ensemble des autres membres et peut donc leur diffuser l information. Si l objectif visé n est pas d obtenir les propriétés d obscurcissement des systèmes F2F [134], les performances des différentes approches d adaptation du réseau hôte sont similaires à celles associées à cette propriété. De même, le système nécessite l utilisation de méthodes de découverte des pairs afin de répondre aux besoins des recherches sur un index distribué sans sémantique et des index locaux. Dans le premier cas, le mécanisme de découverte le plus adapté est celui par identifiant, en associant l identifiant des pairs aux identifiants des entrées de l index distribué dont ils ont la charge. Pour les index locaux, le mécanisme de recherche correspond à de la découverte par propriétés partielle. En effet, les recherches sur les index locaux sont limitées aux pairs appartenant à une même institution et donc potentiellement toutes liées aux représentants de cette institution. Au vu des propriétés désirées, l approche la plus adaptée correspond à un overlay structuré (Tableau 6.6). En revanche, contrairement aux systèmes structurés classiques, comme Chord [151], il est nécessaire d utiliser des mécanismes pour obtenir les propriétés d un overlay structuré sur les bases d une construction suivant le modèle d ami à ami [142, 52], comme c est le cas dans Freenet 0.7 [142]. Bien que les performances de routage de ce type d approches soient inférieures à celles d un overlay structuré classique, elles permettent néanmoins de répondre à l ensemble de nos besoins. Table 6.6 Performance des approches d adaptation du réseau hôte par rapport aux besoins du système Serveur d adressagchisturturé Overlay simple Overlay hiérar- Overlay struc- Overlay struc- et hiérarchisé Passage à l échelle Tolérance aux pannes Découverte par propriétés partielle Par identifiant Obscurcissement

157 6.3. Proposition du système Vue d ensemble du système proposé Notre système repose sur un overlay unique construit par les interactions entre les utilisateurs [120]. Cette construction se fait par une interface de gestion de contact et de liste de diffusions. Ainsi, à chaque projet auquel participe un utilisateur est associé la liste des membres du groupe projet. Dans cette liste, on distingue deux types de membre, les membres de confiance qui seront destinataires des nouveaux documents mis en partage ainsi que des nouvelles révisions et les autres membres du projet qui ne seront qu en copie de ces documents et révisions. Un pair ne crée des connexions qu avec les membres de confiance d un groupe projet. Ainsi, pour intégrer un groupe projet, il faut que l utilisateur partage au moins un lien de confiance avec un membre de ce groupe. De même, si plus aucun membre du groupe ne partage de lien de confiance avec un utilisateur, celui-ci est exclu du groupe de travail. L overlay ainsi formé est utilisé pour diffuser les documents et leurs révisions à l ensemble des membres d un groupe de travail à l aide d un algorithme de propagation de rumeur. Chaque utilisateur pouvant intégrer plusieurs groupes de projet, l agrégation de l ensemble des overlay formés permet d obtenir un overlay tendant à relier l ensemble des utilisateurs du système. Cet overlay est rendu navigable [92] à l aide d un algorithme de placement des pairs dans un espace métrique [142, 52]. Cet overlay est utilisé pour créer un système de recherche documentaire permettant la mutualisation des documents publics détenus par les utilisateurs. Ce système de recherche repose sur un fichier inversé qui est distribué sur l ensemble des pairs. Pour distribuer ce fichier, nous utilisons une approche hybride entre une approche par termes et une approche par documents reposant sur un index distribué sans sémantique. Chaque mot-clef utilisé pour décrire les documents est indexé par un identifiant issu d une fonction de hachage et stocké dans notre index distribué. Pour chacun de ces mots-clefs, l index renvoie la liste de documents qui y sont associés comme dans une approche par termes, mais aussi la liste des autres mots-clefs associés à chacun de ces documents comme dans une approche par documents. Cette approche de distribution permet de réduire à la fois la quantité de messages échangés et les traitements nécessaires à la résolution d un requête, au prix d une augmentation de la taille de l index. Pour la recherche ciblant des documents confidentiels extérieurs aux échanges internes aux groupes de projet, par exemple avec des services de valorisation scientifique, le système utilise une diffusion de la requête à l ensemble des pairs liés à une même institution. Pour assurer la maintenance du fichier inversé ainsi que les fonctionnalités de stockage sûr des documents, le système utilise un deuxième index distribué sans sémantique pour indexer les documents présents dans le système. Tous les documents sont identifiés par une empreinte issue d une fonction de hachage [3] et sont associés à un ensemble d informations qui leurs sont relatives. Parmi ses informations, on retrouve l ensemble des mots-clefs auxquels ce document est associé, les identifiants des pairs hébergeant des copies de ce document ainsi que les identifiants des pairs hébergeant les fragments du 141

158 Chapitre 6. Proposition d un système P2P pour les archives scientifiques document utilisé pour son archivage semi-courant. En effet, pour archiver sur une longue durée les documents, notre système les encode à l aide d un code à effacement [38] et les fragmentent de sorte que chacun de ces fragments soit distribué sur des pairs différents du système. Cette distribution est guidée par un troisième index distribué sans sémantique dans lequel chacun des fragments est identifié par son empreinte issue d une fonction de hachage. L intégrité de chacun des fragments est périodiquement vérifiée par le pair qui l héberge et si celle-ci est compromise, le pair responsable de l indexation du document est averti et retire ce fragment de la liste des fragments associés à ce document. Sous un seuil donné de fragments associés à un document, le pair responsable de l indexation de ce dernier récupère les fragments restant pour reformer le document et recréer de nouveaux fragments afin de garantir l intégrité de l archivage. Enfin, notre système propose un outil afin de permettre aux utilisateurs d attribuer des mots-clefs aux documents auxquels ils sont en mesure d accéder. Ce sont ces mots-clefs qui seront utilisés pour retrouver un document dans notre système de recherche documentaire. L attribution des mots-clefs est effectuée librement par les utilisateurs selon un modèle de folksonomie [70], comparable à celui que l on trouve dans le système Del.icio.us 32. Cette approche est agnostique en ce qui concerne les types et les formats des documents partagés par les utilisateurs, dans le sens où n importe quel utilisateur ayant accès à un document peut le lire et donc le décrire. De même, cette approche permet de tenir compte des multiples points de vue potentiellement contradictoires des utilisateurs par rapport à un même document, ce qui enrichit les capacités de recherche de notre système. Enfin, les propriétés de répartition des mots-clefs entre les documents spécifiques à une folksonomie permettent de limiter l impact de l augmentation de la taille de notre fichier inversé distribué. En effet, le nombre de mots-clefs associés à un document, ainsi que le nombre de documents associés à un même mot-clef suivent tous les deux une loi de Zipf [70]. L intérêt pour le système est de limiter la redondance au niveau de notre fichier inversé distribué à une proportion restreinte des documents stockés dans le système et de réduire les coûts de calculs en évitant d interroger les pairs responsables des mots-clefs les plus utilisés. 6.4 Comparaison avec d autres approches existantes La principale originalité de notre système repose sur notre distribution hybride du fichier inversé utilisé pour le mécanisme de recherche documentaire. En effet, même si leur utilisation est détournée par rapport à leur système d origine, l utilisation du modèle d ami à ami pour les outils de travail collaboratif [134, 129] et l organisation de ce type de système pour former un overlay navigable [142, 52] ont déjà été validées dans plusieurs études. Ainsi, dans cette section, nous comparons les performances de notre approche de dis- 32. Delicious - Discover Yourself!, 142

159 6.4. Comparaison avec d autres approches existantes tribution hybride d un fichier inversé par rapport aux approches par documents et par termes. Notre comparaison tiendra sur deux critères : le traitement des requêtes et la taille de l index. Chacune de ces comparaisons repose sur l analyse de ces différentes approches Traitement des requêtes Pour estimer les performances dans le traitement d une requête nous considérerons quatre points : le nombre de pairs contactés, la quantité de données transmises, la complexité des traitements effectués et le nombre de pannes minimum pouvant entrainer un résultat incomplet Nombre de pairs contactés Dans une approche par documents, le nombre de pairs devant être contactés correspond à l ensemble des n pairs du système, ce qui correspond au pire cas possible pour ce critère [178]. Dans une approche par termes, un nombre R t de pairs doivent être contactés, avec R t le nombre de mots-clefs de la requête [178]. Cette approche est donc meilleure qu une approche par documents, mais encore inférieure à notre index hybride qui nécessite de ne contacter qu un seul des pairs responsables d un mot-clef présent dans la requête Quantité de données transmises Au niveau de la quantité de données transmises, notre approche possède des performances égales à une approche par documents. En effet, toutes deux retournent uniquement les données correspondantes à la réponse à la requête, ce qui est l optimum. À l inverse, dans une approche par termes, les listes de l ensemble des documents associés à chacun des mots-clefs de la requête sont retournées, soit en moyenne R t D t [?,?] avec D t le nombre moyen de documents associés à un mots-clefs.invertedfilesfortextsearchengines Complexité des traitements Une approche par termes nécessite d effectuer l intersection des R t listes de documents associés à l un des termes de la requête. Cela correspond donc à une complexité moyenne de O(T d R t ), avec T d le nombre moyen de mots-clefs associés à un document. Notre approche et l approche par document filtrent les entrées du fichier inversé. Dans une approche par documents, l ensemble du fichier inversé est vérifié, soit O(D), avec D le nombre de documents. Notre approche est plus efficace, car seuls les documents associés à un mot-clef de la requête sont considérés, soit en moyenne O(T d ). 143

160 Chapitre 6. Proposition d un système P2P pour les archives scientifiques Nombre minimum de pannes pouvant entrainer un résultat incomplet Dans une approche par documents, l absence d un pair peut compromettre la complétude du résultat. De même, une approche par termes nécessite que l ensemble des pairs responsables d un des mots-clefs présent dans la requête soit disponible pour que le résultat soit calculé. Dans notre approche, tous les pairs responsables d un mot-clef présent dans la requête peuvent calculer le résultat complet. Notre approche est donc plus tolérante aux pannes que les deux précédentes approches Taille de l index La principale limite de notre approche repose sur l augmentation significative de la taille de l index par rapport aux approches par documents et par termes. Pour quantifier cette augmentation, nous comparons la taille de ces différents types d index. La croissance des différents index correspond aux équations données dans le tableau 6.7, avec T le nombre de mots-clefs différents présents utilisés dans le système. Comme prévu, la taille de notre index hybride est bien plus élevée que celles des approches par documents et par termes. Par rapport à une approche par documents, la taille de notre index croit plus vite. En effet, un grand nombre de documents peuvent partager les mêmes mots-clefs, ainsi T D t sera toujours plus grand que D, même s il est difficile de quantifier cet écart. La comparaison par rapport à une approche par termes est plus directe, notre index hybride correspondant à un enrichissement de celle-ci. Ainsi, la taille de notre index croît plus rapidement par un facteur proportionnel à T d qui tend à être constant [70]. En considérant que les documents indexés dans le système correspondent aux documents détenus par les pairs [166], la quantité de documents indexés est alors proportionnelle au nombre de pairs présent dans le système. Dans ce cas, cette augmentation de la taille de l index correspond, au niveau de chaque pair à une multiplication par un facteur proportionnel à T d de l espace de stockage nécessaire. Cette augmentation est soutenable en regard de la quantité de mémoire allouée par chaque pair pour l index [103]. Table 6.7 Croissance de la taille de l index en fonction de l approche de distribution retenue Par documents Par termes Notre approche Taille de l index D T d T D t T D t T d Bilan de la comparaison Notre approche hybride pour la distribution d un fichier inversé propose un nouveau compromis par rapport aux approches existantes (Tableau 6.8). En effet, les approches par documents permettent d effectuer des recherches par mots-clefs avec une faible quantité 144

161 6.4. Comparaison avec d autres approches existantes de traitements pour chacun des pairs et une faible quantité d informations échangée, mais au prix d un très grand nombre de messages transmis. À l inverse, les approches par termes ne nécessitent que très peu de messages échangés entre les pairs, mais au prix d une plus grande quantité d informations transmises et d importants traitements pour calculer les résultats des requêtes. En revanche, notre approche ne nécessite ni une importante quantité de traitements, ni un grand nombre de messages transmis, ni même une importante quantité de messages échangés, mais seulement une capacité de stockage plus importante de la part des pairs participant au système. Table 6.8 Comparaison des performances de notre approche hybride par rapport aux approches par documents et par termes Par documents Par termes Notre approche Nombre de messages Quantité de données transmises Complexité calculs des Nombre de pairs présents dans le système (N) Seulement les réponses à la requête O(D) avec D le nombre de documents indexés Nombre de mots-clefs composant la requête (R t ) R t listes de documents soit R t D t, avec D t le nombre moyen de document associés à un mot-clef Un seul Seulement les réponses à la requête En moyenne O(D Rt t ) En moyenne O(D t ) Tolérance aux Une seule Une seule R t pannes Taille de l index D T d avec T d le T D t T D t T d, avec T nombre moyen de mots-clefs par document le nombre de motsclefs différents dans l index Cette augmentation est toutefois très importante et n est acceptable dans notre cas uniquement parce que notre fichier inversé est créé selon un modèle de folksonomie [70]. En effet, notre approche de distribution conduit à une augmentation de la taille du fichier inversé, par rapport à une approche par termes proportionnelle au nombre moyen de motsclefs associé à un document. Or, l utilisation d une folksonomie pour créer le fichier inversé induit que ce nombre de mots-clefs reste très faible en moyenne. En effet, le nombre de mots-clefs associés par document suit une loi de Zipf [70], ce qui implique que la grande majorité des documents ne sont associés qu à un nombre très faible de mots-clefs. Ainsi, si notre solution est beaucoup plus performante que les approches classiques, en termes de quantité de données transmises, de nombre de messages échangés et de quantité de traitement, elle implique des limites qui ne sont acceptables que dans certains 145

162 Chapitre 6. Proposition d un système P2P pour les archives scientifiques cas, comme celui d un fichier inversé créé par une folksonomie. 6.5 Conclusion L étude du cas des archives scientifiques et plus particulièrement du cahier de laboratoire numérique met en avant la capacité de notre grille d analyse d identifier les manques dans l existantes et à quel niveau il est nécessaire de proposer une nouvelle approche pour répondre aux besoins d un contexte applicatif donné. En effet, l étude du cas d un fournisseur de services à l habitat a montré que notre grille d analyse permettait de dégager des solutions issues l existant, mais appartenant à d autres domaine d application des systèmes P2P. En revanche, l étude du cas du cahier de laboratoire montre que notre grille d analyse permet aussi de dégager les limites des solutions existantes. En effet, aucune approche de distribution d un fichier inversé ne permettait de répondre aux besoins de notre projet. Il a donc fallu trouver une nouvelle approche qui corresponde à un compromis plus adapté à ces besoins. De même, les besoins relatifs au développement d un cahier de laboratoire numérique étant très différents de ceux d un système de fournisseur de services, les deux systèmes P2P obtenus sont très différents l un de l autre. En effet, dans le cas d un fournisseur de services à l habitat, les besoins ne généraient aucune incompatibilité les uns avec les autres, le système P2P obtenu est donc assez simple avec une seule approche utilisée au niveau de la couche d indexation. À l inverse, les besoins appliqués au système P2P de cahier de laboratoire numérique ne permettaient pas de dégager une solution unique et ont donc nécessité l utilisation de quatre approches différentes au niveau de la couche d indexation. Ce constat renvoie aussi à l importance de cette couche dans le développement d un système P2P. En effet, comme nous le montre l analyse des propriétés de l existant dans le chapitre 3, les différentes approches de la couche d indexation correspondent toutes à des compromis particuliers, aucune n étant intrinsèquement meilleure qu une autre. Ainsi, plus les fonctionnalités devant être développées par le système sont complexes, plus il est nécessaire d utiliser plusieurs approches au niveau de la couche d indexation pour répondre à l ensemble des besoins. 146

163 CONCLUSION ET PERSPECTIVES Conclusion Depuis le début des années 2000, les systèmes P2P sont devenus un domaine d étude très dynamique, comme en témoigne les 5500 articles disponibles sur le sujet dans la bibliothèque numérique des ACM 33. Si l engouement pour les systèmes P2P est une bonne chose, il est aujourd hui très difficile d avoir une vue d ensemble de l existant proposé au cours de ces douze dernières années sur le domaine. De plus, les états de l art sur les systèmes P2P, lesquels ont été principalement proposés autour des années 2005, ne permettent plus de donner une vue d ensemble du domaine tel qu il existe actuellement. Or sans ce recul et cette vue d ensemble, les propositions existantes dans le domaine des systèmes P2P sont difficilement réutilisables. Ainsi, bien que cet existant soit très fourni, il n existe aucune méthode permettant de composer un système P2P afin de répondre à un besoin donné sur la base des systèmes de l état de l art. Pour répondre à cette limite, nous avons, dans un premier temps, proposé un nouvel état de l art des systèmes P2P. La particularité de notre état de l art est qu il repose sur une analyse fonctionnelle de ces systèmes P2P pour définir ses critères de classification. Ainsi, les systèmes ne sont plus classés par rapport à leurs propriétés macroscopiques, comme c est le cas dans la plupart des classifications existantes, mais par rapport aux approches qui ont été employées pour répondre aux fonctionnalités de base qu ils doivent mettre en œuvre. Nous avons dégagé trois fonctionnalités qui composent un système P2P que nous avons organisé dans un modèle en couche : la couche d adaptation du réseau hôte, la couche d indexation des ressources et la couche d application. Pour chacune de ces couches, l analyse des systèmes existants nous a permis de déterminer différentes approches permettant de réaliser les fonctionnalités de cette couche. Ainsi, cette analyse nous a permis de dégager les composants de base d un système P2P et ainsi définir des 33. ACM Digital Library : 147

164 Chapitre 6. Proposition d un système P2P pour les archives scientifiques ensembles d approches pouvant servir à la composition de nouveaux systèmes P2P. Afin de pouvoir composer des systèmes P2P adaptés à un contexte applicatif donné à partir de l existant, il nous a été nécessaire d analyser les propriétés de chacune des approches que nous avons dégagées. En effet, il est nécessaire de connaitre les propriétés des différentes approches pouvant être utilisées pour composer un système P2P afin de pouvoir choisir celles qui sont les plus adaptées pour répondre aux besoins d un contexte donné. Nous avons présenté les résultats de cette étude sous la forme d une grille d analyse de sorte à faciliter son utilisation pour la composition de systèmes P2P en fonction d un ensemble de besoins. Nous avons testé notre grille d analyse afin de proposer des systèmes P2P dans le cadre de deux projets distincts : un projet industriel sur un système de fournisseur de services à l habitat et un projet régional sur les archives scientifiques. Dans le premier cas, notre grille d analyse nous a permis de composer un système P2P basé sur des approches initialement développées pour d autres contextes applicatifs et permettant de répondre plus efficacement que les systèmes existants dans ce domaine. À l inverse, dans notre deuxième cas d étude, notre grille d analyse nous a permis de mettre en évidence qu aucune approche existante ne permettait de répondre de façon satisfaisante à nos besoins. Cela nous a permis d isoler la fonctionnalité sur laquelle nous devions travailler et ainsi proposer facilement une nouvelle approche pour répondre à ce type de besoin. Dans ces deux cas, notre grille d analyse nous a permis d exploiter plus efficacement les approches ayant été développées précédemment dans l ensemble des systèmes basés sur le modèle P2P et de guider nos réflexions pour la composition de ces systèmes P2P. Perspectives Les travaux présentés dans cette thèse nous ont permis de montrer à la fois la faisabilité et la pertinence du développement d une grille d analyse pour la composition de systèmes P2P à partir de l existant afin de pouvoir répondre aux besoins spécifiques d un contexte applicatif. Ainsi, si nous avons pu valider la méthode sur des problèmes concrets il nous reste à l utiliser pour composer des systèmes P2P dans d autres contextes applicatifs. Cependant notre grille d analyse nécessite d être affinée sur plusieurs points qui pourront faire l objet de futur travaux. Premièrement, il serait nécessaire de pousser plus avant la classification des approches pour chacune des couches fonctionnelles. En effet, si le niveau de granularité de classification actuelle permet de mettre en évidence de nouveaux éléments par rapport aux classifications précédentes, certains éléments nécessiteraient d être plus approfondis pour améliorer les performances de notre grille d analyse. Cela est particulièrement vrai pour la couche d adaptation du réseau hôte qui a focalisé une grande partie de l attention de la communauté scientifique au cours de ces douze dernières années. Ainsi, il serait intéressant de considérer des éléments supplémentaires pour caractériser le fonctionnement des 148

165 6.5. Conclusion overlays, comme le mécanisme de retransmission des messages. De même, notre grille d analyse est basée sur une analyse qualitative des différentes approches que nous avons dégagées, plutôt que quantitative. Ce choix a été fait afin de limiter la complexité de l étude et ainsi pouvoir la mener à bien dans la durée d une thèse. En effet, l analyse quantitative de propriétés comme la latence des transmissions, la tolérance aux pannes et le passage à l échelle est particulièrement complexe, car elle repose sur l interaction de plusieurs couches fonctionnelles. Effectuer cette analyse quantitative est néanmoins intéressante car elle ouvre la possibilité de création de nouveaux outils pour la conception de systèmes P2P comme celle d un simulateur générique qui permettrait de tester rapidement un système composé de différentes approches. Enfin, comme l a montré notre étude du cas des archives scientifiques, notre grille d analyse permet de mettre en évidence des manques dans l existant et de proposer des solutions qui sont réutilisables dans la composition d un nouveau système. Ainsi, l utilisation de notre grille d analyse pour la conception de systèmes dans le cadre de différents contextes applicatifs devrait permettre d augmenter le nombre d approches réutilisables pour la composition de futurs systèmes. 149

166

167 BIBLIOGRAPHIE [1] Basic reference model : The basic model, open systems interconnection (osi). Organisation Internationale de standardisation, [2] Iso-7498 : Information processing systems, open systems inter-connection, basic reference model, part 2 : Security architecture. Organisation internationale de standardisation (ISO), [3] Secure hash standard. National Institute of Standards and Technology, April [4] Jxta v1.0 protocols specification. Tech. rep., SUN Microsystems, http :// June [5] Risk management guide for information technology systems. National Institute of Standards and Technology, Decembre [6] Jxta v2.0 protocols specification. Tech. rep., SUN Microsystems, http ://jxtaspec.dev.java.net/nonav/jxtaprotocols.html, [7] Nist framework and roadmap for smart grid interoperability standards. NIST Special Publication 1108, National Institute of Standards and Technology (NIST), January [8] Abadi, D. J., Ahmad, Y., Balazinska, M., Cetintemel, U., Cherniack, M., Hwang, J.-H., Lindner, W., Maskey, A. S., Rasin, A., Ryvkina, E., Tatbul, N., Xing, Y., and Zdonik, S. The design of the borealis stream processing engine. In Conference on Innovative Data Systems Research (CIDR) (January 2005). [9] Abrams, C., and Schulte, R. Service-oriented architecture overview and guide to soa research. Gartner Research Publication G , Gartner, January [10] Adya, A., Bolosky, W., Castro, M., Cermak, G., Chaiken, R., Douceur, J., Howell, J., Lorch, J., Theimer, M., and Wattenhofer, R. Farsite : federated, available, and reliable storage for an incompletely trusted environment. ACM SIGOPS Operating Systems Review 30, SI (2002),

168 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [11] Albert, R., Jeong, H., and Barabási, A. Error and attack tolerance of complex networks. Nature 406 (2000), [12] Alon, N., and Luby, M. A linear time erasure-resilient code with nearly optimal recovery. IEEE Transactions on Information Theory 42, 6 (November 1996), [13] Amdahl, G. Validity of the single processor approach to achieving large scale computing capabilities. In Spring Joint Computer Conference (April 1967), pp [14] Anderson, D. Boinc : A system for public-resource computing and storage. In International Workshop on Grid Computing (November ), ACM, pp [15] Anderson, D., Cobb, J., Korpela, E., Lebofsky, M., and Werthimer, D. Seti@home : an experiment in public-resource computing. Communications of the ACM 45, 11 (November 2002), [16] Androutselis-Theotokis, S., and Spinellis, D. A survey of peer-to-peer content distribution technologies. ACM Computing Survey 36, 4 (2004), [17] Atitallah, S., Abou Khaled, O., Sokhn, M., and Mugellini, E. Knowledge management in next generation networks. In International Conference on Software Engineering and Knowledge Engineering (July 2011), pp [18] Babaoglu, O., Marzolla, M., and Tamburini, M. Design and implementation of a p2p cloud system. In Symposium on Applied Computing (2012), pp [19] Banaei-Kashani, F., and Shahabi, C. Swam : a family of access methods for similarity-search in peer-to-peer data networks. In International conference on Information and knowledge management (November 2004), ACM. [20] Banerjee, S., Bhattacharjee, B., and Kommareddy, C. Scalable application layer multicast. In Conference on Applications, technologies, architectures, and protocols for computer communications (August 2002). [21] Barkai, D. P2p computing. Intel Press (2002). [22] Baset, S., and Schulzrinne, H. An analysis of the skype peer-to-peer internet telephony protocol. In IEEE Infocom 06 (April 2006), IEEE, Ed., IEEE, IEEE. [23] Bees, D. Home gateway initiative : Next steps on smart energy. In Information and Communication Technology for Sustainable Homes (2009). [24] Bénel, A., Calabretto, S., Iacovella, A., and Pinon, J.-M. Porphyry 2001 : Semantics for scholarly publications retrieval. In International Symposium on Methodologies for Intelligent Systems (June 2002), vol of Lecture Notes in Artificial Intelligence, Springer-Verlag, pp [25] Bhagwan, R., Tati, K., Cheng, Y., Savage, S., and Voelker, G. Total recall : system support for automated availability management. In Symposium on Networked Systems Design and Implementation (March 2004). 152

169 6.5. Conclusion [26] Bindel, D., Chen, Y., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon, H., Weimer, W., Wells, C., Zhao, B., and Kubiatowicz, J. Oceanstore : An extremely wide-area storage system. Tech. Rep. CSD , University of California at Berkeley, Berkeley, CA, [27] Binzenhofer, A., Kunzmann, G., and Henjes, R. A scalable algorithm to monitor chord-based p2p systems at runtime. In International Parallel and Distributed Processing Symposium (2006). [28] Birman, K. The promise, and limitations, of gossip protocols. ACM SIGOPS Operating Systems Review 41(5) (2007), [29] Birman, K., Hayden, M., Ozkasap, O., Xiao, Z., Budiu, M., and Minsky, Y. Bimodal multicast. ACM Transactions on Computer Systems 17, 2 (May 1999), [30] Bonnet, F., Kermarrec, A.-M., and Raynal, M. Small-world networks : from theoretical bounds to practical systems. In Conference On Principles Of Distributed Systems (OPODIS 07) (2007), Springer-Verlag, Ed., vol of LNCS, pp [31] Boukhelef, D., and Kitagawa, H. Efficient multidimensional data management in structured peer-to-peer systems. In VLDB (August 2009). [32] Camarillo, G. Peer-to-peer (p2p) architecture : Definition, taxonomies, examples and applicability. Tech. Rep. RFC 5694, IETF, [33] Castro, M., Costa, M., and Rowstron, A. Should we build gnutella on a structured overlay? SIGCOMM Computer Communication Review 34, 1 (2004), [34] Castro, M., Druschel, P., Kermarrec, A.-M., Nandi, A., Rowstron, A., and Singh, A. Splitstream : high-bandwidth multicast in cooperative environments. In the nineteenth ACM symposium on Operating systems principles (October 2003). [35] Castro, M., Druschel, P., Kermarrec, A.-M., and Rowstron, A. Scribe : a large-scale and decentralized applicatioin-level multicast infrastructure. IEEE Journal on Selected Areas in Communications (2002). [36] Castro, M., and Liskov, B. Practical byzantine fault tolerance. In Symposium on Operating systems design and implementation (New Orleans, Louisiana, United States, February 1999), pp [37] Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., and Shenker, S. Making gnutella-like p2p systems scalable. In Applications, technologies, architectures, and protocols for computer communications (Karlsruhe, Germany, August 2003), pp

170 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [38] Chen, Y., Edler, J., Goldberg, A., Gottlieb, A., Sobti, S., and Yianilos, P. A prototype implementation of archival intermemory. In Conference on Digital Libraries (August 1999), ACM, pp [39] Chu, Y., Rao, S. G., Seshan, S., and Zhang, H. A case for end system multicast. IEEE Journal on Selected Areas in Communication : Networking Support for Multicast 20, 8 (2002), [40] Clarke, I., Sandberg, O., Wiley, B., and Hong, T. Freenet : A distributed anonymous information storage and retrieval system. In Workshop on Design Issues in Anonymity and Unobservability (2000), pp [41] Costello, A. M. Robust peer-to-peer protocols via randomized forwarding. PhD thesis, University of California at Berkeley, [42] Cuenca-Acuna, F., Peery, C., Martin, R., and Nguyen, T. Planetp : Using gossiping to build content addressable peer-to-peer information sharing communities. In 12th IEEE International Symposium on High Performance Distributed Computing (HPDC 03) (June 2003), p [43] D. Watts, S. S. Collective dynamics of small-world networks. Nature 393 (1998). [44] Dam, M., and Stadler, R. A generic protocol for network state aggregation. In the Radiovetenskap och Kommunikation (2005). [45] Darlagiannis, V. Hybrid peer-to-peer systems. In P2P Systems and Applications (2005), vol of LNCS, Springer-Verlag, pp [46] Darlagiannis, V. Overlay Network Mechanisms for Peer-to-Peer Systems. PhD thesis, Darmstadt Technical University, [47] De Smedt, A., Balemans, H., Onnegren, J., and D Haeseleer, S. The multi-play service enabled residential gateway. In Broadband Europe (2006). [48] de standardisation, O. I. Iso : Document management electronic document file format for long term preservation part 1 : Use of pdf 1.4 (pdf/a-1), October [49] Dean, J. Challenges in building large-scale information retrieval systems : invited talk. In International Conference on Web Search and Data Mining (2009), ACM, pp [50] Dean, J., and Ghemawat, S. Mapreduce : simplified data processing on large clusters. Communications of the ACM 51, 1 (January 2008), [51] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., and Vogels, W. Dynamo : amazon s highly available key-value store. In SIGOPS symposium on Operating systems principles (October 2007), vol. 41, ACM, pp [52] Dell Amico, M. Mapping small worlds. In Peer-to-Peer Computing (2007), IEEE, pp

171 6.5. Conclusion [53] Divac-Krnic, L., and Ackermann, R. Security-related issues in peer-to-peer networks. In P2P Systems and Applications (2005), vol of LNCS, Springer- Verlag, pp [54] Doulkeridis, C., Vlachou, A., Kotidis, Y., and Vazirgiannis, M. Peer-topeer similarity search in metric spaces. In Very large data bases (Vienna, Austria, 2007), pp [55] Eberspächer, J., and Schollmeier, R. First and second generation of peerto-peer systems. In P2P Systems and Applications (2005), vol of LNCS, Springer-Verlag, pp [56] El-Sayed, A., Roca, V., Mathy, L., Center, R., and Inria, F. A survey of proposals for an alternative group communication service. IEEE Network 17 (2003), [57] Enokido, T., Barolli, L., and Takizawa, M. Jamjuree cluster : A peer-to-peer cluster computing system. In International Conference on Network-Based Information Systems (2007), vol of LNCS, Springer-Verlag, pp [58] Falchi, F., Gennaro, C., and Zezula, P. A content-addressable network for similarity search in metric spaces. In Databases, Information Systems and Peer-to- Peer Computing (2005), pp [59] Fayçal, M., and Serhrouchn, A. Netpopps : A network provider oriented peer-to-peer system. In International Conference on New Technologies, Mobility and Security (November 2008), pp [60] Freedman, M. Experiences with coralcdn : a five-year operational view. In Conference on Networked systems design and implementation (April 2010), USNIX, pp [61] Galatopoullos, D., Kalofonos, D., and Manolakos, E. A p2p soa enabling group collaboration through service composition. In International conference on Pervasive services (Sorrento, Italy, 2008), pp [62] Ganesan, P., Gummadi, K., and Garcia-Molina, H. Canon in g major : Designing dhts with hierarchical structure. In International Conference on Distributed Computing Systems (March 2004), pp [63] Ganesh, A., Kermarrec, A.-M., and Massoulié, L. Scamp : Peer-to-peer lightweight membership service for large-scale group communication. In International Workshop on Networked Group Communication (November 2001), pp [64] Ghemawat, S., Gobioff, H., and Leung, S. The google file system. ACM SIGOPS Operating Systems Review 37, 5 (December 2003), [65] Gonzalez Prieto, A., and Stadler, R. A-gap : an adaptive protocol for continuous network monitoring with accuracy objectives. IEEE Transactions on Network and Service Management 4(1) (2007),

172 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [66] Götz, S., Reiche, S., and Wehrle, K. Selected dht algorithms. In P2P Systems and Applications (2005), vol of LNCS, pp [67] Graffi, K., Stingl, D., Gross, C., Nguyen, H., Kovacevic, A., and Steinmetz, R. Towards a p2p cloud : Reliable resource reservations in unreliable p2p systems. In International Conference on Parallel and Distributed Systems (2010), IEEE. [68] Green, M. Napster opens pandora s box : Examining how file-sharing services threaten the enforcement of copyright on the internet. Ohio State Law Journal 63, 799 (2002). [69] Gummadi, K., Gummadi, R., Gribble, S., Ratnasamy, S., Shenker, S., and Stoica, I. The impact of dht routing geometry on resilience and proximity. In Applications, technologies, architectures, and protocols for computer communications (Karlsruhe, Germany, August 2003), pp [70] Gupta, M., Li, R., Yin, Z., and Han, J. Survey on social tagging techniques. ACM SIGKDD Explorations Newsletter 12, 1 (June 2010). [71] Haeberlen, A., Mislove, A., and Druschel, P. Glacier : highly durable, decentralized storage despite massive correlated failures. In Symposium on Networked Systems Design and Implementation (May 2005), pp [72] Hall, Y., Piemonte, P., and Weyant, M. Joost : A measurement study. Tech. rep., Carnegie Mellon University, May [73] Haridasan, M., and van Renesse, R. Gossip-based distribution estimation in peer-to-peer networks. In International Workshop on Peer-to-Peer Systems (2008). [74] Hart, D. Using ami to realize the smart grid. In IEEE PES General Meeting (2008), IEEE, Ed., pp [75] Heckmann, O., and Bock, A. The edonkey 2000 protocol. Tech. Rep. KOM Technical Report 08/2002, Darmstadt University of Technology, [76] Hwang, J., Cetintemel, U., and Zdonik, S. Fast and reliable stream processing over wide area networks. In International Workshop on Scalable Stream Processing Systems (April 2007), IEEE. [77] Ibáñez, M., Martínez Madrid, N., Seepold, R., van Willigenburg, W., and Balemans, H. An osgi-based model for remote management of residential gateways. In Asia-Pacific Network Operations and Management Symposium on Managing Next Generation Networks and Services (2007). [78] Isdal, T., Piatek, M., Krishnamurthy, A., and Andreson, T. Friend-tofriend data sharing with oneswarm. Tech. rep., University of Washington, [79] Izal, M., Urvoy-Keller, G., Biersack, E., Felber, P., Hamra, A., and Garces-Erice, L. Dissecting bittorrent : Five months in a torrent s lifetime. In Passive and Active Measurements (2004). 156

173 6.5. Conclusion [80] J. Risson, J., and Moors, T. Survey of research towards robust peer-to-peer networks : Search methods. Tech. Rep. RFC 4981, IETF, [81] Jagadish, H., Ooi, B., Tan, K., Yu, C., and Zhang, R. idistance : An adaptive b+-tree based indexing method for nearest neighbor search. ACM Transactions on Database Systems 30, 2 (June 2005), [82] Jelasity, M., Montresor, A., and Babaoglu, O. Gossip-based aggregation in large dynamic networks. ACM transactions on computer systems 23(3) (2005), [83] Jervis, M., and Masoodian, M. Evaluation of an integrated paper and digital document management system. In international conference on Human-computer interaction (2011), pp [84] Jurca, D., and R. Stadler, R. Computing histograms of local variables for realtime monitoring using aggregation trees. In International Symposium on Integrated Network Management (2009), IFIP/IEEE. [85] Kalt, C. Internet relay chat : Architecture. Tech. Rep. RFC 2810, IETF, April [86] Karger, D., and Ruhl, M. Simple efficient load balancing algorithms for peer-topeer systems. In Symposium on Parallelism in algorithms and architectures (June 2004), ACM. [87] Karp, R., Schindelhauer, C., Shenker, S., and Vocking, B. Randomized rumor spreading. In Symposium on Foundations of Computer Science (November 2000.), p. p.565. [88] Keen, M., Acharya, A., Beshop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., and Verschueren, P. Patterns : Implementing an soa using an enterprise service bus. IBM Redbooks SG , 2004, IBM, [89] Kempe, D., Dobra, A., and Gehrke, J. Gossip-based computation of aggregate information. In Symposium on Foundations of Computer Science (2003), IEEE, pp [90] Kempe, D., Kleinberg, J., and Demers, A. Spatial gossip and resource location protocols. In Symposium on Theory of computing (2001), ACM, pp [91] King, R., Hameurlain, A., and Morvan, F. Ontology-based data source localization in a structured peer-to-peer environment. In International symposium on Database engineering and applications (September 2008). [92] Kleinberg, J. The small-world phenomenon : An algorithmic perspective. Tech. Rep. TR , Cornell University, [93] Kniesburges, S., Koutsopoulos, A., and Scheideler, C. Re-chord : a selfstabilizing chord overlay network. In symposium on Parallelism in algorithms and architectures (June 2011), ACM, pp

174 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [94] Konishi, K., Furukawa, N., and Ikeda, H. Data model and architecture of a paper-digital document management system. In symposium on Document engineering (2007), ACM, pp [95] Kubiatowicz, J. Extracting guarantees from chaos. Communications of the ACM 46, 2 (February 2003), [96] Kunze, J., and Baker, T. The dublin core metadata element set. Tech. Rep. RFC 5013, IETF, August [97] Kurasawa, H., Wakaki, H., Takasu, A., and Adachi, J. Data allocation scheme based on term weight for p2p information retrieval. In international workshop on Web information and data management (Lisbon, Portugal, 2007), ACM, pp [98] Kurian, J., and Sarac, K. A survey on the design, applications, and enhancements of application-layer overlay networks. ACM Computing Surveys (CSUR) 43, 1 (November 2010), [99] Le Merrer, E., Kermarrec, A.-M., and Massoulié, L. Peer to peer size estimation in large and dynamic networks : a comparative study. In International Symposium on High Performance Distributed Computing (2006), IEEE. [100] Leong, B., Liskov, B., and Demaine, D. Epichord : Parallelizing the chord lookup algorithm with reactive routing state management. Computer Communications 29, 9 (2006), [101] Lesueur, F., Me, L., and Tong, V. An efficient distributed pki for structured p2p networks. In International Conference on Peer-to-Peer Computing (September 2009), IEEE, pp [102] Li, B., Xie, S., Keung, G., and Zhang, X. Coolstreaming : Design, theory, and practice. IEEE Transactions on Multimedia 9, 8 (December 2007), [103] Li, J., Loo, B., Hellerstein, J., Kaashoek, M., Karger, D., and Morris, R. On the feasibility of peer-to-peer web indexing and search. In International Workshop on Peer to Peer Systems (January 2003), pp [104] Liang, J., Kumar, R., and Ross, K. The fasttrack overlay : A measurement study. Computer Networks : The International Journal of Computer and Telecommunications Networking 50, 6 (April 2006), [105] Loo, B., Huebsch, R., Stoica, I., and Hellerstein, J. The case for a hybrid p2p search infrastructure. In international conference on Peer-to-Peer Systems (2004), pp [106] López de Vergara, J., Villagrá, V., Fadón, C., González, J., Lozano, J., and Álvarez-Campana, M.. An autonomic approach to offer services in osgibased home gateways. Computer Communications 31, 13 (August 2008),

175 6.5. Conclusion [107] Lu, J., Xie, D., and Ai, Q. Research on smart grid in china. In Transmission and Distribution Conference and Exposition : Asia and Pacific (2009). [108] Lua, E., Crowcroft, J., Pias, M., Ravi, S., and Lim, S. A survey and comparison of peer-to-peer overlay network schemes. IEEE Communication Surveys and Tutorials (March 2005). [109] Lv, Q., Cao, P., Cohen, E., Li, K., and Shenker, S. Search and replication in unstructured peer-to-peer networks. In International Conference on Supercomputing (New York, USA, 2002). [110] Mackay, V. Potential and challenges of smart energy management today. In Information and Communication Technology for Sustainable Homes (2009). [111] Makhloufi, R., Bonnet, G., Doyen, G., and Gaïti, D. Decentralized aggregation protocols in peer-to-peer networks : A survey. In International Workshop on Modelling Autonomic Communications (October 2009), IEEE, pp [112] Malkhi, D., Naor, M., and Ratajczak, D. Viceroy : a scalable and dynamic emulation of the butterfly. In twenty-first annual symposium on Principles of distributed computing (July 2002). [113] Manku, G., Bawa, M., and Raghavan, P. Symphony : distributed hashing in a small world. In USENIX Symposium on Internet Technologies and Systems (Seattle, WA, March 2003), pp [114] Manku, G., Naor, M., and Wieder, U. Know thy neighbor s neighbor : the power of lookahead in randomized p2p networks. In symposium on Theory of computing (June 2004), ACM. [115] Martins, R., Lopes, L., and Silva, F. A peer-to-peer middleware platform for fault-tolerant, qos, real-time computing. In Middleware-application interaction : affiliated with the DisCoTec federated conferences (Oslo, Norway, 2008), pp [116] Mathy, L., Canonico, R., and Hutchison, D. An overlay tree building control protocol. In Internationa Workshop on Networked Group Communication (November 2001), pp [117] Maymounkov, P., and Mazières, D. Kademlia : A peer-to-peer information system based on the xor metric. In International Workshop on Peer-to-Peer Systems (March 2002), pp [118] McDonough, J., Olendorf, R., Kirschenbaum, M., Kraus, K., Reside, D., Donahue, R., Phelps, A., Egert, C., Lowood, H., and Rojo, S. Preserving virtual worlds final report. Tech. rep., Library of Congress, [119] Melamed, R., and Keidar, I. Araneola : A scalable reliable multicast system for dynamic environments. Journal of Parallel and Distributed Computing 68, 12 (December 2008),

176 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [120] Merle, F., Benel, A., Doyen, G., and Gaiti, D. Decentralized documents authoring system for decentralized teamwork : matching architecture with organizational structure. In GROUP (October 2012), ACM, pp [121] Milgram, S. The small world problem. Psychology Today (1967). [122] Montoya, M. Smart grid strategy and deployment. In Load Management Standards Workshop on Smart Grid Activities and Technology (April 2008). [123] Mourad, A., and Ahmed, M. A scalable approach for application layer multicast in p2p networks. In International Conference on Pervasive Computing and Communications (2008), IEEE, pp [124] Nejdl, W., Wolf, B., Qu, C., Decker, S., Sintek, M., Naeve, A., Nilsson, N., Palmér, M., and Risch, T. Edutella : a p2p networking infrastructure based on rdf. In International World Wide Web Conference (Honolulu, Hawaii, USA, 2002), pp [125] Novak, D., and Zezula, P. M-chord : a scalable distributed similarity search structure. In InfoScale (2006), p. 19. [126] Patterson, D., Gibson, G., and Katz, R. A case for redundant arrays of inexpensive disks (raid). In international conference on Management of data (SIGMOD) (1988), ACM, pp [127] Pendarakis, D., Shi, S., Verma, D., and Waldvogel, M. Almi : an application level multicast infrastructure. In Symposium on Internet Technologies and Systems (March 2001), USENIX, Ed., pp [128] Perotin, Y. L administration et les trois âges des archives. Seine et Paris, 20 (1961), 1 4. [129] Popescu, B., Crispo, B., and Tanenbaum, A. Safe and private data sharing with turtle : Friends team-up and beat the system. LNCS : Security Protocols 3957 (Septembre 2006), [130] Potter, C., Archambault, A., and Westrick, K. Building a smarter smart grid through better renewable energy information. In Power Systems Conference and Exposition, (2009), IEEE. [131] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and Schenker, S. A scalable content-addressable network. In Applications, technologies, architectures, and protocols for computer communications (San Diego, California, United States., August 2001), pp [132] Repantis, T., Gu, X., and Kalogeraki, V. Synergy : sharing-aware component composition for distributed stream processing systems. In International Conference on Middleware (November 2006), ACM/IFIP/USENIX. [133] Reynolds, P., and Vahdat, A. Efficient peer-to-peer keyword searching. In International Conference on Middleware (June 2003), ACM/IFIP/USENIX. 160

177 6.5. Conclusion [134] Rogers, M., and Bhatti, S. How to disappear completely : A survey of private peer-to-peer networks. In International Workshop on Sustaining Privacy in Autonomous Collaborative Environments (July 2007), IFIP. [135] Rowstron, A. I. T., and Druschel, P. Pastry : Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In International Conference on Distributed Systems Platforms (Heidelberg, November 2001), IFIP/ACM, pp [136] Royon, Y., Frénot, S., and Le Mouël, F. Virtualization of service gateways in multi-provider environments. In International Symposium on Component-Based Software Engineering (2006). [137] Royon, Y., Parrend, P., Frénot, S., Papastefanos, S., Abdelnur, H., and Van de Poel, D. Multi-service, multi-protocol management for residential gateways. In BroadBand Europe (2007). [138] Rubacha, M., Rattan, A., and Hosselet, S. A review of electronic laboratory notebooks available in the market today. Journal of Laboratory Automation 16, 1 (Feb 2011), [139] Rusitschka, S., Gerdes, C., and Eger, K. A low-cost alternative to smart metering infrastructure based on peer-to-peer technologies. In International Conference on the European Energy Market (May 2009), pp [140] Saint-Andre, P. Extensible messaging and presence protocol (xmpp) : Core. Tech. Rep. RFC 6120, IETF, March [141] Sanchez Artigas, M., Garcia Lopez, P., and Gomez-Skarmeta, A. Deca : a hierarchical framework for decentralized aggregation in dhts. In International Workshop on Distributed Systems Operations and Management (2006), IFIP/IEEE, pp [142] Sandberg, O. Neighbor selection and hitting probability in small-world graphs. Annals of Applied Probability 18, 5 (2008), [143] Sardouk, A., Rahim-Amoud, R., Merghem-Boulahia, L., and Gaïti, D. Power-aware agent-solution for information communication in wsn. Telecommunication Systems 48, 3-4 (2011), [144] Saroiu, S., Gummadi, P., and Gribble, S. D. A measurement study of peerto-peer file sharing systems. In Multimedia Computing and Networking (San Jose, CA, January 2002). [145] Shu, Y., Ooi, B., Tan, K., and Zhou, A. Supporting multi-dimensional range queries in peer-to-peer systems. In Peer-to-Peer Computing (2005), pp [146] Shudo, K., Tanaka, Y., and Sekiguchi, S. P3 : P2p-based middleware enabling transfer and aggregation of computational resources. In International Symposium on Cluster Computing and the Grid (May 2005), vol. 1, IEEE, pp

178 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [147] Sokhn, M., Mugellini, E., Abou Khaled, O., and Serhrouchni, A. Endto-end adaptive framework for multimedia information retrieval. In International Conference on Wired/Wireless Internet Communications (2011), IFIP, pp [148] Steiner, M., En-Najjary, T., and Biersack, E. Long term study of peer behavior in the kad dht. IEEE/ACM Transactions on Networking (TON) 17, 5 (October 2009), [149] Steinmetz, R., and Wehrle, K. Peer-to-peer-networking and computing. Informatik-Spektrum 27, (2004). [150] Steinmetz, R., and Wehrle, K. What is this peer-to-peer about? In P2P Systems and Applications (2005), vol of LNCS, Springer-Verlag, pp [151] Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., and Balakrishnan, H. Chord : A scalable peer-to-peer lookup service for internet applications. In Applications, technologies, architectures, and protocols for computer communications (San Diego, California, United States, August 2001), pp [152] Suel, T., Mathur, C., Wu, J., Zhang, J., Delis, A., Kharrazi, M., Long, X., and Shanmugasundaram, K. Odissea : A peer-to-peer architecture for scalable web search and information retrieval. In International Workshop on the Web and Databases (June 2003), pp [153] Sun, X. Scan : a small-world structured p2p overlay for multi-dimensional queries. In World Wide Web Conference (May 2007). [154] Tabard, A., Mackay, W., and Eastmond, E. From individual to collaborative : the evolution of prism, a hybrid laboratory notebook. In Conference on Computer supported cooperative work (2008), ACM, pp [155] Tan, S., Waters, G., and Crawford, J. A performance comparison of selforganising application layer multicast overlay construction techniques. Computer Communications 29, 12 (August 2006), [156] Tang, A. Pg&e s smart grid vision. In Load Management Standards Workshop on Smart Grid Activities and Technology (April 2008). [157] Tigelaar, A., Hiemstra, D., and Trieschnigg, D. Peer-to-peer information retrieval : An overview. ACM Transactions on Information Systems 30, 2 (May 2012). [158] Turnbull, J. Introducing home area networks. BT Technology Journal 20, 2 (April 2002), [159] Ullah, I., Doyen, G., Bonnet, G., and Gaïti, D. A survey and synthesis of user behavior measurements in p2p streaming systems. IEEE Communication Tutorials and Surveys (2012). 162

179 6.5. Conclusion [160] Van Renesse, R., Birman, K., and Vogels, W. Astrolabe : a robust and scalable technology for distributed system monitoring, management, and data mining. ACM transactions on computer systems 21, 2 (2003), [161] Van Renesse, R., and Bozdog, A. Willow : Dht, aggregation, publish/subscribe in one protocol. In IPTPS (February 2004). [162] Venayagamoorthy, G. Potentials and promises of computational intelligence for smart grids. In IEEE PES General Meeting (2009). [163] Weatherspoon, H., Eaton, P., Chun, B., and Kubiatowicz, J. Antiquity : exploiting a secure log for wide-area distributed storage. In SIGOPS/EuroSys European Conference on Computer Systems (May 2007), ACM. [164] Wehrle, K., S. Götz, S., and Reiche, S. Distributed hash tables. In P2P Systems and Applications (2005), vol of LNCS, Springer-Verlag, pp [165] Weikum, G. From Active Data Management to Even-Based Systems and More, vol of LNCS. Springer-Verlag, 2010 ch. Peer-to-Peer Web Search : Euphoria, Achievements, Disillusionment, and Future Opportunities, pp. pp [166] Weikum, G. Peer-to-peer web search : Euphoria, achievements, disillusionment, and future opportunities. LNCS From Active Data Management to Even-Based Systems and More 6462 (2010), [167] Welfelé, O. Organiser le désordre : usages du cahiers de laboratoire en physique contemporaine. Alliage, (1999). [168] Xu, K., Song, M., Zhang, X., and Song, J. A cloud computing platform based on p2p. In International Symposium on IT in Medicine Education (August 2009), IEEE, pp [169] Yalagandula, P., and Dahlin, M. Sdims : A scalable distributed information management system. Technical Report TR-03-47, Department of computer science at University of Texas, Austin, September [170] Yalagandula, P., and Dahlin, M. A scalable distributed information management system. In Conference on Applications, technologies, architectures, and protocols for computer communications (August 2004). [171] Yang, B., and Garcia-Molina, H. Comparing hybrid peer-to-peer systems. In VLDB (Roma, Italy, 2001). [172] Yang, B., and Garcia-Molina, H. Designing a super-peer network. In International Conference on Data Engineering (2003). [173] Zeadally, S., and Kubher, P. Internet access to heterogeneous home area network devices with an osgi-based residential gateway. International Journal of Ad Hoc and Ubiquitous Computing (2007). [174] Zeilemaker, N., Capotă, M., Bakker, A., and Pouwelse, J. Tribler : P2p media search and sharing. In international conference on Multimedia (November 2011), ACM, pp

180 Chapitre 6. Proposition d un système P2P pour les archives scientifiques [175] Zezula, P., Amato, G., Dohnal, V., and Batko, M. Similarity Search : The Metric Space Approach, vol. 32 of Advances in Database Systems. Springer, [176] Zhang, H., Goel, A., and Govindan, R. Using the small-world model to improve freenet performance. ACM SIGCOMM Computer Communication Review 32, 1 (January 2002). [177] Zhao, B. Y., Huang, L., Stribling, J., Kubiatowicz, J. D., Joseph, A. D., and Rhea, S. C. Tapestry : A resilient global-scale overlay for service deployment. Tech. Rep. CSD , University of California at Berkeley, [178] Zobel, J., and Moffat, A. Inverted files for text search engines. ACM Computing Surveys (CSUR) 38, 2 (2006), 6 es. [179] Zoels, S., Despotovic, Z., and Kellerer, W. On hierarchical dht systems an analytical approach for optimal designs. Computer Communications 31, 3 (February 2008),

181 Annexes 165

182

183 ÉTATS DE L ART SPÉCIFIQUES AUX BESOINS DES DIFFÉRENTS CONTEXTES APPLICATIFS CONSIDÉRÉS 1 Les systèmes de multicast applicatif en P2P Les systèmes de multicast applicatif (ou ALM) sur un système P2P sont des systèmes qui permettent de diffuser des messages sur l ensemble des membres d un groupe de pairs d un système P2P. De ce fait, on peut différencier les ALM classiques des systèmes de vidéo streaming comme CoolStreaming [102] ou des systèmes de diffusions de fichier comme Bittorrent [79] par les propriétés suivantes : les messages sont envoyés de façon ponctuelle contrairement au streaming où les messages sont envoyés de façon continue [102] ; les messages sont indépendants les uns des autres contrairement au streaming où les messages doivent arriver dans un ordre prédéfini [102] ; la source de chaque message est unique contrairement à la diffusion de fichier ou au streaming où les sources sont généralement multiples pour assurer un débit important [102, 34] ; les messages sont de taille limitée contrairement à la diffusion de fichier et ne peuvent donc pas toujours être fragmentés [102, 34]. Enfin, nous ne considérerons que les systèmes qui sont purement dédiés au multicast applicatif. En effet, nous nous intéressons ici aux optimisations développées dans le but d améliorer les performances de multicast applicatif. Ainsi, les systèmes de supervision tels 167

184 États de l art spécifiques aux besoins des différents contextes applicatifs considérés qu Astrolabe [160], SDIMS [169, 170] ou Willow [161] qui supportent des fonctionnalités de multicast ne sont pas traités ici. De même, les systèmes d échange de fichiers comme Gnutella 0.6 dont le fonctionnement est similaire à du multicast, à savoir la diffusion des requêtes à l ensemble des pairs susceptibles de posséder la ressource recherchée, ne sont pas, non plus, pris en compte ici. 1.1 Les approches par arbre Les approches à base d arbre consistent à créer un arbre reliant l ensemble des pairs du groupe de multicast et de l utiliser pour diffuser les messages. De façon générale, les approches à base d arbre sont les approches les plus optimisées en termes de nombres de messages nécessaires pour diffuser une information sur l ensemble d un groupe. En revanche, ces approches ne sont pas tolérantes aux pannes. En effet, si un nœud de l arbre vient à tomber en panne, une partie, voir l ensemble de l arbre devra être reconstruit avant de pouvoir à nouveau diffuser efficacement un message sur le groupe. On distingue généralement deux approches pour la création de l arbre de diffusion : les approches mesh en premier et les approches arbre en premier [56, 155] Les approches mesh en premier Les approches mesh en premier consistent à intégrer les pairs dans un overlay et d utiliser ensuite cet overlay pour créer l arbre de diffusion pour relier les pairs d un même groupe. Quand un pair intègre ce type de système, il commence par se connecter à l overlay qui relie l ensemble des pairs du système. Une fois que le pair fait partie du système, il rejoint ensuite un groupe de diffusion en utilisant l overlay pour communiquer avec les autres pairs du groupe. Il est enfin intégré à l arbre du groupe et peut ensuite envoyer et recevoir les messages diffusés [35, 39]. La principale variation que l on retrouve dans les approches de type mesh en premier se situe dans le choix de l overlay qui est utilisé par le système. Dans le cas de Narada [39], c est un overlay non structuré qui est utilisé. Dans ce système, chaque pair maintient une liste de l ensemble des membres du groupe et de leurs connexions. Cette liste est échangée périodiquement entre les voisins dans l overlay pour assurer la maintenance du système et permettre à chaque pair de calculer les arbres de diffusions de chaque source potentielle du groupe. Pour Scribe [35], c est l overlay structuré Pastry [135] qui est utilisé. Contrairement à l overlay créé par Narada, Pastry apporte de nombreuses fonctionnalités qui sont utilisées par Scribe pour diffuser les messages aux membres du groupe. En premier lieu, chaque groupe est identifié par une empreinte indexée dans la table de hachage distribué de Pastry de sorte que le pair qui à la responsabilité de la partie de l index correspondante soit aussi la racine de l arbre de diffusion du groupe. Chaque nouveau pair qui souhaite 168

185 1. Les systèmes de multicast applicatif en P2P intégrer le groupe utilise une version modifiée du routage de Pastry pour contacter la racine du groupe de sorte à créer dynamiquement l arbre de diffusion tout au long de la retransmission de cette requête et ainsi tirer aux mieux partis de la structure en arbre optimisé de Pastry. Les approches mesh en premier sont principalement caractérisées par une bonne résilience ainsi qu une bonne latence dans la transmission des messages [155]. Ce dernier point s explique principalement par le fait que l arbre lui-même est issu de l optimisation de l overlay préalablement déployé. En revanche, les approches mesh en premier nécessitent la maintenance de l overlay ce qui génère une consommation de ressources réseau supplémentaire par rapport au simple maintient de l arbre Les approches arbre en premier Les approches de type arbre en premier consistent à intégrer directement les pairs rejoignant le groupe à l arbre de diffusion, sans passer préalablement par un overlay comme dans les approches mesh en premier. Quand un pair intègre un groupe de diffusion, il contacte un pair de ce groupe ou un point de rendez-vous avec qui il va négocier son positionnement dans l arbre de diffusion. On distingue principalement trois approches pour intégrer un pair dans un groupe dans les arbre en premier : les approches centralisées [127], les approches par grappe [20] et les approches par permutation [116]. Comme leur nom l indique, les approches centralisées, telle qu ALMI [127], reposent sur l utilisation d une autorité centrale qui à la charge de maintenir l arbre optimisé en gérant les liens qui relient les pairs entre eux. Techniquement, dans ALMI, chaque pair du groupe renvoie des informations au contrôleur central qui calcule l organisation optimale de l arbre de diffusion. Ainsi quand un nouveau pair arrive dans le système, il contacte le contrôleur qui recalcule l arbre optimal en tenant compte de ce nouveau membre et lui indique les liens qui doit maintenir avec les autres membres du groupe. Dans les approches par grappe telle que NICE [20], les pairs d un groupe sont regroupés dans des sous-groupes de tailles fixes appelés grappes. Dans chaque grappe, les pairs élisent un représentant qui va participer à une grappe regroupant des représentants d autre grappe et ainsi de suite jusqu à former un arbre de diffusion. Chaque nouveau pair qui intègre le groupe est placé dans une grappe au plus bas niveau de l arbre. Si le nombre de pairs présents dans une grappe dépasse la limite fixée, la grappe est divisée en deux nouvelles grappes qui élisent chacune un nouveau représentant. Enfin, dans une approche par permutation comme dans TBCP [116], chaque pair qui intègre le groupe se connecte directement à la racine de l arbre. Ensuite ce pair échange de position avec soit un pair au même niveau de l arbre soit avec son père soit avec un de ses fils afin de trouver sa position optimale dans l arbre. Les approches arbre en premier sont globalement moins résilientes que les approches mesh en premier [155], principalement parce qu ils ne bénéficient généralement pas de 169

186 États de l art spécifiques aux besoins des différents contextes applicatifs considérés liens de secours pour communiquer avec les autres pairs du groupe en cas de panne. En revanche, cette limitation du nombre de liens aux seuls nécessaires à la diffusion des messages font des approches arbre en premier les approches les plus optimisées en termes de coût de communication. 1.2 Les approches par rumeur Les approches à base de rumeur reposent sur l utilisation d algorithmes épidémiques pour diffuser les messages sur l ensemble des pairs d un groupe. Dans ce type d approche, les pairs du groupe sont interconnectés les uns aux autres par un unique overlay. Quand un pair du groupe souhaite diffuser un message aux autres pairs, il choisit aléatoirement un de ses voisins et lui envoie le message. Ce pair devient infecté par la rumeur. Ainsi, au tour suivant, lui et le pair initiateur du message choisissent chacun un voisin pour lui envoyer le message et l infecter à son tour [63]. La fin de la propagation de la rumeur peut se faire de deux façons possibles. La première consiste à avoir un nombre de tours déterminé au bout duquel la propagation s arrête. Ce mécanisme ne garantissant pas que l ensemble des pairs ait reçu le message, il doit être complété par un deuxième mécanisme où chaque pair demande périodiquement à un voisin choisi aléatoirement la liste des dernières rumeurs qu il a reçues. Si une rumeur de cette liste n est pas connue du pair, il demande alors à ce voisin de la lui communiquer, ce qui permet alors de garantir que tous les pairs reçoivent bien l ensemble des messages diffusés par le système [29, 87]. Le deuxième mécanisme possible est d imposer à chaque pair de transmettre le message à l ensemble de ces voisins. Ainsi, si un pair est connecté à l overlay, il est garanti, en l absence de perte de messages, qu il reçoive la rumeur. En revanche, cette technique créer une forte réplication des messages sur le réseau et implique donc un coût plus élevé que la précédente [119]. La principale caractéristique des approches par rumeur est d être très robuste. En effet, étant basées sur des mécanismes aléatoires, elles sont très peu sensibles aux pannes d un ou plusieurs pairs. En revanche, les approches par rumeur impliquent un fort surcoût en termes de nombre de messages échangés par rapport aux approches par arbre. De plus, leur latence, même si elle peut croître logarithmiquement avec le nombre de pairs présents dans le groupe, reste relativement élevée par rapport aux approches par arbre. 1.3 Comparaison des systèmes Les différentes approches existantes sont comparées en fonction des critères relatifs à nos besoins que sont : la capacité de passage à l échelle, la tolérance aux pannes, l équilibre de la charge et le nombre total de messages échangés par le mécanisme. Les deux premiers correspondent directement aux besoins architecturaux du système. L équilibre de la charge est une donnée importante, car les gateway sont toutes identiques. Ainsi, si la charge 170

187 2. Les systèmes de supervision distribuée en P2P n est pas équilibrée, les pairs les plus chargés devront faire partie du SI du fournisseur de services, ce qui affecte le choix des approches que l on peut retenir pour le design de notre système. Enfin, le nombre de messages nécessaires pour mener à bien le mécanisme renvoie au coût de communication. En effet, si les technologies utilisées par les pairs pour communiquer sont payantes, le mécanisme nécessitant le moins de messages sera le plus adapté. À partir du tableau 5.3, on constate qu aucune des approches existantes ne permet de répondre à nos besoins. En effet, aucune approche par arbre ne permet de tolérer les pannes, car si celles-ci affectent des pairs proches de la racine, tous les pairs qui y sont reliés ne reçoivent plus les messages tant que l arbre n est pas reconstruit. À l inverse, si les approches à base de rumeurs sont tolérantes aux pannes, elles nécessitent l envoi d un nombre très important de messages ce qui est contraire à notre objectif de réduction des coûts de communications. 2 Les systèmes de supervision distribuée en P2P Il existe de nombreux systèmes P2P de supervision qui sont tous basés sur l agrégation de données. Ces systèmes permettent d obtenir des informations sur l état général d un système basées sur indicateurs générés par des fonctions d agrégations, comme des sommes, des moyennes... Si ces données agrégées sont suffisantes pour superviser certains systèmes, elles ne permettent pas de répondre à l ensemble de nos besoins de supervision. Pourtant, comme tous les systèmes P2P de supervision reposent sur ses approches, nous les étudions afin de voir si les mécanismes qu ils mettent en œuvre peuvent être réutilisées dans notre système. On peut distinguer trois types d approches [111] pour réaliser un système de supervision reposant sur le modèle P2P, les approches par arbre, par rumeur ou les approches hiérarchiques. 2.1 Les approches par arbre Comme leur nom l indique, les approches par arbre utilisent un ou plusieurs arbres reliant l ensemble des pairs d un groupe afin de faire remonter les informations sur le système à la racine de celui-ci. Dans ce type d approches, il est nécessaire de créer l arbre qui va relier l ensemble des pairs du groupe. L approche utilisée dans les systèmes de la famille des GAP [44, 65, 84], pour sa création est de désigner un pair initiateur qui devient la racine de l arbre. Ce pair envoie un message épidémique à l ensemble de ses voisins qui deviennent ces fils et qui vont retransmettre le message à leurs voisins qui deviendront eux-mêmes leurs fils. Les feuilles de l arbre étant les pairs qui ne possèdent pas de voisins n ayant pas déjà été intégrés à l arbre. 171

188 États de l art spécifiques aux besoins des différents contextes applicatifs considérés Table 1 Comparaison des systèmes de multicast applicatif Passage à l échelle Tolérance Équilibre de Nombre total aux pannes la charge de messages échangés Approches mesh en premier Narada [39] Non (O(n) information Non Non O(n) collectée pour maintenir l arbre) Scribe [35] Oui (O(1) états Non Non O(n) conservés par pair et O(1) messages échangés correspondant au nombre de fils dans l arbre) Approches arbre en premier ALMI [127] Non (serveur central Non Non O(n) collectant O(n) informations pour maintenir l arbre) Nice [20] Oui (O(1) correspondant Non Non O(n) au nombre de fils de chaque pairs) TBCP [116] Oui (O(1) correspondant Non Non O(n) au nombre de fils de chaque pairs) Approches à base de rumeur Araneola [119] SCAMP [63] Oui (O(1) messages échangés pour la diffusion et O(1) informations à maintenir par pairs) Oui (O(log(n)) messages échangés pour la diffusion et O(1) informations à maintenir par pairs) Oui Oui O(k n) avec k le nombre de liens par pairs Oui Oui O(n*log(n)) Il existe d autres approches pour créer des arbres dont principalement celles qui reposent sur l utilisation de la topologie d un système P2P structuré comme c est le cas dans SDIMS [170, 169] qui utilisent un arbre dédié pour chaque type de données ou Willow 172

189 2. Les systèmes de supervision distribuée en P2P [161] qui utilise un arbre unique. En effet, les systèmes P2P structurés peuvent généralement être représentés sous la forme d un ou plusieurs arbres qui sont donc utilisés par les mécanismes de supervisions. Une fois cet arbre créé, les données devant être collectées remontent l arbre depuis les feuilles jusqu à la racine et sont agrégées ou concaténées à chaque nœuds [44, 65, 84, 170, 169, 161]. De cette façon, chaque nœud de l arbre contient les données agrégées ou concaténées de l ensemble des pairs dont il est le parent. Ainsi, la racine de l arbre contient quant à lui, une vision d ensemble de toutes les données collectées par le système. L avantage des approches par arbre est qu en absence de pannes ou d attrition, ils permettent d obtenir des valeurs exactes sur les données collectées [44]. De plus, les approches par arbre nécessitent peu de messages avec un peu moins de deux messages par pairs [44]. En revanche, la structure en arbre n est pas tolérante aux pannes. Ainsi, si un pair quitte le groupe ou tombe en panne pendant la collecte des informations, cela peut entraîner des erreurs dans la valeur finale [44]. Cette erreur est d autant plus importante que le pair en question est proche de la racine. De même, la charge n est pas équilibrée entre les pairs du groupe. En effet, les feuilles de l arbre n effectuent aucun traitement contrairement aux nœuds qui reçoivent et traitent toutes les données de leurs fils. Enfin, concernant le passage à l échelle, ce dernier est pris en charge pour les données agrégées dont la taille reste fixe à tous les niveaux de l arbre [44]. En revanche, pour les données concaténées, plus on remonte vers la racine de l arbre plus la taille de ces données augmente. En effet, chaque nœud de l arbre maintient la concaténation de l ensemble des informations collectées par ces fils dans l arbre, ce qui, au niveau de la racine, correspond à n entrées pour chaque attribut, avec n le nombre de pairs dans le groupe. Le système ne passe donc pas l échelle si l on concatène les informations sur l ensemble de l arbre jusqu à la racine. 2.2 Les approches par rumeur Les approches par rumeur consistent en l échanger de données entre les pairs du groupe afin qu ils puissent déterminer des informations globales sur l ensemble du système. Ces approches reposent sur l utilisation des algorithmes épidémiques pour propager des données afin que chaque pair puisse déterminer des informations agrégées ou concaténées sur l ensemble du groupe [89, 90, 73, 82]. Techniquement, chaque pair du groupe choisit aléatoirement un de ces voisins et échange avec lui les données qu il souhaite agréger ou concaténer. Une fois l échange effectué, chaque pair recalcule la valeur de ses données à partir des informations obtenues. La procédure recommence ainsi t fois, de sorte qu à la fin de ces t tours, l ensemble des valeurs maintenues par les pairs ait convergé vers la valeur exacte [89]. Les approches par rumeur sont particulièrement robustes du fait que chaque pair du groupe maintient en local l ensemble des données agrégées ou concaténées et que les 173

190 États de l art spécifiques aux besoins des différents contextes applicatifs considérés communications reposent sur un choix aléatoire des voisins [28]. De même, cette approche assure l équilibre de la charge entre l ensemble des pairs du système [28]. En effet, chaque pair du système échange le même nombre de messages à chaque tour et le nombre de tours est le même pour tous les pairs du système. En revanche, comme les approches probabilistes, les approches par rumeur ne permettent d obtenir que des approximations des valeurs recherchées [99]. En effet, les valeurs calculées par chaque pair du système convergent vers les valeurs exactes sans permettre de garantir leur exactitude. Cependant, cette approximation reste très faible, avec une approximation sur le résultat de l ordre d un pour cent [99]. De plus, si chaque pair échange un nombre limité de messages, environs quatre messages par tours, la quantité de messages échangés sur l ensemble du système est très élevée par rapport aux approches par arbre [99]. Enfin, ces approches passent à l échelle pour les données agrégées du fait de leur taille fixe [89]. En revanche, chaque pair du système conservant une copie des données, ces approches ne peuvent pas passer à l échelle pour ce type de données [28]. En effet, la taille des données concaténées étant proportionnelle au nombre de pairs, chaque pair doit alors conserver et échanger une quantité de données croissante avec l augmentation du nombre de pairs présent dans le groupe. 2.3 Les approches hiérarchiques Les approches hiérarchiques reposent sur la segmentation sur plusieurs niveaux du groupe de pairs supervisé. Ces approches visent donc à associer les propriétés des approches par arbre avec celles d autres approches plus robustes. Le principe de ces approches est donc de former des sous-groupes pairs de tailles modérés et de créer une hiérarchie pour les relier les uns aux autres [160, 141, 27]. Les mécanismes régissant la collecte et le traitement des données au sein des sous-groupes dépendent fortement des propriétés que l on souhaite obtenir pour le système. Ainsi, dans Astrolabe [160] et DECA [141], les sous-groupes utilisent des approches par rumeur pour collecter les données ce qui permet d obtenir une meilleure robustesse qu une approche par arbre classique. À l inverse, l approche de A. Binzenhöfer [27] utilise une approche par arbre pour traiter en parallèle chaque sous-groupe et ainsi accélérer la collecte des informations tout en limitant le nombre de messages échangés. Pour créer la hiérarchie qui relie les groupes, plusieurs solutions sont aussi proposées. Astrolabe [160] élit des pairs dans les sous-groupes pour qu ils servent de représentant à un niveau supérieur de la hiérarchie et participe à un mécanisme de rumeur avec les représentants d autres sous-groupes. Dans DECA [141], les sous-groupes sont reliés entre eux par un arbre généré à partir d une topologie structurée de sorte que chaque sousgroupe soit composé des pairs possédant des identifiants ayant le même suffixe. Enfin, l approche de A. Binzenhöfer [27] utilise l initiateur de la requête comme point central pour collecter l ensemble des données agrégées ou concaténées par chacun des sous-groupes. 174

191 2. Les systèmes de supervision distribuée en P2P Les approches hiérarchiques sont par nature très flexibles dans le sens où chaque sous-groupe est indépendant des autres et peut, en théorie, utiliser n importe quel type de mécanisme pour agréger ou concaténer les données des pairs qui le composent [160]. Ainsi, les propriétés obtenues peuvent varier en fonction des mécanismes choisis. De plus, les données collectées à chaque niveau de la hiérarchie du système peuvent être traitées de façons différentes [160], ce qui permettre une plus grande flexibilité dans la représentation des résultats. Au niveau du passage à l échelle, ces approches le supportent pour les données agrégées [160, 141, 27]. De plus, chaque sous-groupe ne représentant qu un nombre modéré de pairs, il est possible de concaténer les données au niveau des sous-groupes et d ensuite les agréger aux niveaux supérieurs afin d obtenir des granularités différentes dans la représentation des informations sans pour autant remettre en cause le passage à l échelle du système. En revanche, concaténer les données sur l ensemble du système ne permet pas le passage à l échelle, car la quantité de données générées est alors proportionnelle au nombre de pairs du groupe. 2.4 Comparaison des systèmes Comme pour les systèmes de multicast applicatif ces systèmes sont comparés selon leurs propriétés de capacités de passage à l échelle, la tolérance aux pannes, l équilibre de la charge et le nombre total de messages échangés. De plus, pour chacun de ses systèmes, la capacité de supporter la collecte d autres types d informations que des données agrégées est évaluée. Comme le montre le tableau 5.4, aucun système P2P de supervision ne supporte la collecte de données concaténées, qui permet de percevoir des phénomènes locaux masqués par l agrégation des données, tout en supportant le passage à l échelle. De plus, comme pour les systèmes de multicast applicatif, les approches par arbre ne permettent pas de tolérer les pannes et les approches par rumeurs génèrent une quantité trop importante de messages. En revanche, on peut voir que les approches hiérarchiques se comportent relativement mieux que les autres même si elles impliquent que la charge entre les pairs soit déséquilibrée. 175

192 États de l art spécifiques aux besoins des différents contextes applicatifs considérés GAP [44, 65, 84] SDIMS [170, 169] Kempe [89] Astrolabe [160] Binzenhöfer [27] Table 2 Comparaison des systèmes d agrégation Passage à Tolérance Équilibre de la charge Nombre l échelle aux total de pannes messages échangés Approches par arbre Agrégation Oui (O(1)) Non Non, les pairs feuilles O(n) sont moins chargés que les autres pairs Concaténation Non (O(n)) Non, plus un pair est O(n 2 ) proche de la racine plus il est chargé Agrégation Oui Non, mais Oui la propagation? des erreurs est limitée Concaténation Non Non, plus un pair est proche de la racine,? plus il est chargé Approches par rumeur Agrégation Oui Oui Oui O(n log(n)) (O(log(n))) Concaténation Non O(n 2 log(n)) (O(n log(n))) Approches hiérarchiques Agrégation Oui Oui Non, les représentant O(n log(n)) (O(log(n))) de chaque groupe sont plus chargés que les autres pairs du groupe Concaténation Non O(n 2 log(n)) (O(n log(n))) Agrégation Oui (O(1)) Oui Non, le pair initiateur O(n) est plus chargé que les autres pairs Concaténation Non (O(n)) Non, plus un pair est O(n 2 ) proche de la fin d une sous-section de l anneau, plus il est chargé 176

193 3. Systèmes P2P de stockage sûr 3 Systèmes P2P de stockage sûr Ces systèmes P2P permettent d adresser deux des principales limites à la préservation des documents, à savoir la tolérance aux pannes et la gestion de l obsolescence des technologies de stockage. En effet, ce dernier point est géré par la nature même des systèmes P2P qui permettent de faire collaborer des machines reposant sur du matériel hétérogène. Ainsi, du moment qu une machine peut faire fonctionner un pair, elle peut intégrer le système, quel que soit le matériel sur lequel elle repose. De nombreux systèmes P2P ont été développés pour assurer le stockage sûr de données et ainsi répondre à la problématique de tolérance aux pannes. Tous ces systèmes sont basés sur le principe du modèle Intermemory [38] et fonctionnent comme des systèmes de fichiers distribués (Fig. 6.1). Ainsi, les documents ne sont plus intégralement répliqués sur plusieurs machines, mais réencodés à l aide d un code à effacement [12] et ensuite fragmentés. Cette approche permet de reconstruire un document même si une partie de ses fragments ne peuvent être récupérés. Ce sont donc les fragments des documents qui sont distribués sur le système. Ainsi, cette approche permet d obtenir une meilleure tolérance aux pannes que les approches par réplication [95] grâce à une distribution plus importante. De plus, elle apporte de meilleures garanties en terme de confidentialité, car aucun pair du système ne peut accéder seul à un document. Ce qui permet d utiliser des techniques de tolérance aux pannes byzantines [36], afin de prendre en compte les comportements potentiellement malveillants de certains pairs et ainsi renforcer la sécurité de ces systèmes. Les différents systèmes P2P de stockage sûr qui ont été développés correspondent à différents compromis du même concept d Intermemory [38]. Ainsi, nous présenterons quelques exemples de ces systèmes : OceanStore [26], Glacier [71], Total Recall [25]. 3.1 OceanStore Ce système permet de mutualiser des ressources de serveurs pour permettre l archivage sécurisé de documents. OceanStore [26] a été développé comme un système complet prenant en charge le stockage d archive à court et moyen terme. Pour les archives courantes dans lesquelles les documents sont modifiables, OceanStore utilise un système de gestion de version simplifié pour la traçabilité et de la réplication pour la tolérance aux pannes. Pour assurer l intégrité du document, une version de référence de celui-ci est créée, que l on appelle "réplique primaire". Cette réplique primaire est maintenue par plusieurs serveurs de sorte à pouvoir effectuer un agrément byzantin [36] pour chaque modification qui lui est appliquée. Ainsi, le risque de pannes byzantines au niveau des serveurs est pris en compte. Pour les archives semi-courantes, ce système utilise le concept d Intermemory [38]. Après une période donnée, le document est réencodé à l aide d un code à effacement puis fractionné et distribué entre plusieurs serveurs. Si l accès à un document archivé suivant 177

194 États de l art spécifiques aux besoins des différents contextes applicatifs considérés Figure 1 Encodage et distribution des documents selon le modèle d Intermemory le modèle d Intermemory est relativement long, cette méthode permet d obtenir une tolérance aux pannes très importante pour une redondance assez faible. Enfin, l intégrité des fragments de documents est périodiquement vérifiée par les serveurs et ces derniers sont régénérés à partir de la réplique primaire si l intégrité de trop de fragments est compromise. OceanStore fournit aussi un système de contrôle d accès aux données. Ainsi, chaque document est chiffré afin de ne pouvoir être lu que par les personnes autorisées. En revanche, le contrôle sur les droits d écriture est géré de façon centralisée par une liste d accès au niveau d un serveur désigné comme responsable pour le document. La principale limite d OceanStore est d avoir été conçu pour un réseau de serveurs. Ainsi, si ce système améliore considérablement la pérennité des documents numériques qu il héberge, il souffre des mêmes limites au niveau de son utilisation qu un système de sauvegarde distribué classique. De plus, en proposant un système complet, les mécanismes implémentés dans OceanStore sont difficilement réutilisables indépendamment les uns des autres. Ces dernières années, ces systèmes ont été découpés en blocs fonctionnels indépendants afin de répondre à cette limite. Cela a permis le développement de mécanismes à la fois réutilisables et optimisés comme Antiquity [163] qui fait lui-même partie du projet OceanStore. 178

195 3. Systèmes P2P de stockage sûr 3.2 Glacier Ce système propose une amélioration de l archivage semi-courant de OceanStore [26] afin de le rendre tolérant aux pannes byzantines. Ainsi, Glacier [71] repose sur un réseau de serveurs utilisant le principe d Intermemory [38] pour stocker les documents numériques de façon sûre et pérenne. Ce système repose sur trois principes pour garantir la pérennité des documents : aucune modification ou suppression du document ne peut être effectuée et seules de nouvelles versions peuvent être ajoutées ; le système ne conserve un document que pour une durée de plusieurs mois puis le détruites après ce délai ; la distribution des fragments de documents doit être la plus large possible pour réduire la possibilité de pannes corrélées. Le premier empêche toute réécriture ou modification d un document pendant sa durée de stockage et garantit ainsi son intégrité face à une action malveillante d un des pairs. Le deuxième principe de Glacier permet au système de pouvoir gérer son espace de stockage et ainsi supprimer des versions obsolètes des documents archivés. Enfin, le dernier principe part du postulat qu il est impossible de prendre en compte tous les facteurs pouvant conduire à des pannes byzantines corrélées. Ainsi, la seule solution pour gérer ces pannes est la plus large distribution possible des fragments des documents, ce qui permet de réduire la possibilité de corrélation de telles pannes sur l ensemble des pairs stockant les fragments d un même document. Reposant sur les mêmes principes qu OceanStore ce système souffre donc des mêmes limites quant à l expérience utilisateur. En revanche, il met en évidence les garanties que peut apporter une très forte distribution des données pour limiter l impact de pannes byzantines corrélées. 3.3 Total Recall Ce système propose une solution d archivage reposant sur la mutualisation des ressources des machines des utilisateurs. Comme les deux systèmes précédents, Total Recall [25] utilise le principe d Intermemory [38] pour stocker de façon pérenne les documents numériques des utilisateurs. L apport de ce système est de reposer sur les machines des utilisateurs pour stocker les fragments de documents. L objectif de ce système est de supporter l attrition des pairs qui peut être partiellement négligée dans le cas d une architecture reposant sur les serveurs. Pour ce faire, le système évalue l attrition des pairs afin d essayer de la prévoir. Au niveau du fonctionnement, Total Recall est plus simple que les systèmes précédemment cités. Ainsi, chaque pair du système centralise la responsabilité des documents 179

196 États de l art spécifiques aux besoins des différents contextes applicatifs considérés stockés dont les identifiants sont proches du leur. Quand un pair insère un document dans le système, il calcule l identifiant de celui-ci et envoie le document au pair qui en sera responsable. Ce pair encode le document avec un code à effacement, le fragmente et distribue ensuite ses fragments sur un ensemble de pairs connus de lui seul. Ce système n offre aucun support aux pannes byzantines, car il ne prend pas en compte la présence de pairs malveillants. L avantage de Total Recall [25] est de proposer une implémentation d Intermemory sur une architecture formée par les machines des utilisateurs. En revanche, comme les systèmes précédents, il se contente de reproduire un système de sauvegarde distribué classique et ne considère pas les pratiques des utilisateurs au-delà de l évaluation de leur attrition. 3.4 Comparaison des systèmes Chacun des systèmes présentés apporte des améliorations quant au modèle d archivages sûr de documents numériques. Ainsi, OceanStore [26] propose un système complet et sécurisé allant de la prise en charge des archives courantes et semi-courantes. Glacier [71] propose des améliorations pour l archivage semi-courant afin d offrir des garanties de préservation très élevées, même dans le cas de pannes byzantines. Enfin Total Recall [25] présente la possibilité d utiliser ce modèle de stockage sur un réseau de machines d utilisateurs. La principale limite de ces systèmes est d être uniquement focalisée sur la préservation des documents numériques. Ainsi, ces systèmes n apportent aucune solution quant à la lisibilité des documents autres que leur intégrité. De même, ils ne proposent pas de système de recherche documentaire à part une recherche par identifiant. Ils ne répondent donc que très partiellement à nos besoins. 3.5 Système P2P de recherche documentaire La recherche documentaire sur les systèmes P2P est un domaine très actif. Ainsi, de nombreux systèmes ont été proposés afin de répondre à cette problématique. On peut découper ces systèmes en fonction de deux principaux types de recherche qu ils proposent : les recherches par mots-clefs et les recherches par similarité. 3.6 Approche par mots-clefs Dans un système de recherche par mots-clefs, chaque document est décrit par un ensemble de mots-clefs. Ainsi, dans ces systèmes, seules les mots-clefs décrivant les documents sont considérés par le mécanisme de recherche. C est cette approche qui est majoritairement utilisée dans les moteurs de recherches qu ils soient centralisés ou non. 180

197 3. Systèmes P2P de stockage sûr Machines des clients Cou- Semi rantes Table 3 Comparaison des systèmes de stockage sûr Systèmes Type de pairs Type d archives Integrité Modèle de redondance Documents modifiable OceanStore Serveurs Courantes Tolérance Code à effacement et Oui et Semi aux réplication Courantes pannes byzantines Glacier Serveurs Semi Courantes Tolérance Code à effacement Non aux pannes byzantines Re- Total call Tolérance aux pannes simples Code à effacement Non Ainsi, les systèmes P2P utilisant ce type de recherche se distinguent suivant deux critères : l attribution des mots-clefs et la distribution de l index créé Attribution des mots-clefs Afin de retrouver les documents dans le système, ils doivent être décrits à l aide d un ensemble de mots-clefs. Ainsi, la façon de créer la liste de mots-clefs définira la façon de créer une requête et donc de retrouver un document. De façon générale, l attribution des mots-clefs peut se faire soit de façon automatique soit par une action humaine. Une attribution automatique des mots-clefs est pertinente pour l indexation de documents au moins partiellement textuels. En effet, la description automatique de documents visuels ou sonores ne permet de relever que des informations factuelles et donc assez peu pertinentes pour la recherche humaine. Ainsi, les systèmes généralistes reposant sur une attribution automatique de mots-clefs se contentent souvent des noms de fichiers pour définir les documents. En revanche, sur des documents au moins partiellement textuels, les résultats sont assez satisfaisants, comme le prouvent les moteurs de recherche sur le Web comme Google [49]. En effet, ces systèmes utilisent l ensemble des mots présents dans le texte afin de définir des mots-clefs qu ils pondèrent en fonction de leur importance [178]. Si cette approche génère des index de taille très importante, avec plusieurs centaines de mots-clefs pour décrire un seul document, ils permettent d effectuer des recherches en texte intégral et ainsi proposer des résultats pertinents aux utilisateurs. L attribution des mots-clefs par des humains peut être soit dirigée par un schéma soit libre. Dans le cas d une description dirigée par un schéma, l utilisateur doit indiquer certaines informations pour décrire un document, comme son nom, son type, sa date 181

198 États de l art spécifiques aux besoins des différents contextes applicatifs considérés de création... Certaines normes ont été définies pour unifier les informations nécessaires pour décrire des documents, comme le Dublin Core [96] ou avec une ontologie [147, 17]. Les limites de ces approches sont qu elles sont contraignantes pour les utilisateurs et souvent adaptées à des types de documents spécifiques. À l inverse, une description libre permet à l utilisateur d attribuer n importe quels mots-clefs à un document. L avantage de cette approche est d être applicable à n importe quel type de document quelque soit ses caractéristiques. En revanche, elles ne permettent pas d effectuer de recherche sur un critère particulier, comme l auteur d un document. Ce type de description est utilisé dans les systèmes participatifs (tels que Del.icio.us 34 ) sous le nom de folksonomie [70] Distribution de l index Les index formés par les systèmes de recherche par mots-clefs, que l on appelle fichier inversé, relient des documents et des ensembles de mots-clefs. Deux approches ont été proposées pour distribuer ce type d index [178] sur plusieurs machines : les approches par documents et les approches par termes. Dans une approche par document (Fig. 6.2), chaque document est associé à l ensemble des mots-clefs qui lui ont été attribués. Les documents sont ensuite distribués entre les pairs du système. Pour effectuer une recherche dans ce type de système, l ensemble des pairs doit être contacté afin de pouvoir vérifier pour chaque document si les mots-clefs qui sont associés correspondent à la requête. Ce type d approches permet de distribuer efficacement les traitements entre les pairs et d offrir une forte tolérance aux pannes si la complétude du résultat n est pas nécessaire [49]. En revanche, contacter l ensemble des pairs du système est extrêmement coûteux pour un système P2P où les pairs peuvent être répartis dans le monde entier [55]. Figure 2 Recherche par mots-clefs sur un index distribué par documents Les approches par termes (Fig. 6.3) consistent à associer chaque mot-clef à l ensemble 34. Delicious - Discover Yourself!, 182

199 3. Systèmes P2P de stockage sûr des documents qui lui ont été attribués. Les mots-clefs sont ensuite distribués entre les pairs de sorte à pouvoir retrouver rapidement le pair responsable d un mot-clef précis, comme sur une table de hachage distribué. Pour effectuer une recherche, les pairs responsables de chaque mot-clef composant la requête sont contactés et retournent la liste des documents associés à leurs mots-clefs respectifs. Le résultat est ensuite obtenu par l intersection de l ensemble de ces listes. L avantage de cette approche est de fortement limiter le nombre de messages nécessaire pour effectuer une recherche [103]. En revanche, la quantité d information échangée par les pairs est plus importante qu une approche par document du fait que la taille potentiellement très importante d une liste de documents associés à un terme populaire. Enfin, le calcul des intersections est une opération assez coûteuse en terme de traitement, ce qui est problématique quand les listes possèdent un grand nombre de documents [103]. Figure 3 Recherche par mots-clefs sur un index distribué par terme 3.7 Approche par similarité Le principe de ces approches est de placer les différents documents dans un espace métrique dont les dimensions représentent des propriétés quantifiables afin de pouvoir rechercher des documents en fonction de leur similarité par rapport à point donné de cet espace [175]. Dans ce type de recherche, on définit préalablement l ensemble des dimensions de l espace métrique qui contiendra l ensemble des documents. Chaque dimension doit représenter une propriété quantifiable applicable à l ensemble des documents contenu dans le système, de sorte que la valeur d un document obtenu sur cette propriété serve de coordonnée sur cette dimension de l espace. Cela implique que les documents du système seront classés selon un nombre déterminé et non extensible de propriétés. Cette approche n est donc valable que si l on connait préalablement la nature de l ensemble des documents qui pourront être classés par le système. Deux types de recherches sont possibles avec ce type d approches, les recherches de zone et les recherches des k plus proches voisins. Dans les deux cas, la recherche indique un point de référence dans l espace métrique qui correspond au document que l on souhaite 183

200 États de l art spécifiques aux besoins des différents contextes applicatifs considérés idéalement trouver. Ensuite, dans le cas d une recherche de zone, le système retourne l ensemble des documents se trouvant à une distance inférieure ou égale à la distance indiqué dans la requête du point de référence. Dans le cas d une recherche des k plus proches voisins, le système retournera les k document les plus proches du point de référence. Deux approches ont été proposées pour distribuer des systèmes de recherche par similarité sur un système P2P, les approches par réduction des espaces métriques et les approches par navigation dans ces espaces Réduction des espaces métriques Cette première repose sur des techniques permettant de réduire le nombre de dimensions de l espace à une seule pour le stocker sur un index distribué [125, 58]. Pour ce faire, il existe plusieurs techniques comme les z-curves [145] ou idistance [125, 54] que l on adapte pour obtenir une répartition uniforme des données dans l espace d adressage. L avantage de cette approche est de permettre de gérer la complexité liée au nombre de dimensions de façon proactive. Ainsi, si l ajout, la suppression et la modification sont couteux, le coût d une recherche dans le système reste relativement faible même avec un nombre important de dimensions. Cette approche est donc adaptée à des espaces métriques possédant un grand nombre de dimensions et une population de pairs faiblement sujette à l attrition Navigation dans les espaces métriques La deuxième approche consiste à répartir directement l espace métrique entre les pairs. Les requêtes sont alors transmises aux pairs en charge de la partie de l espace contenant le point de référence de la requête (Fig. 6.4) puis ensuite diffusés à leurs voisins dans l espace métrique si la portée de la requête dépasse leur attribution [19, 153, 31]. La limite de cette approche est de gérer la répartition non uniforme des ressources dans l espace d adressage. En effet, si des techniques ont été proposées pour équilibrer la charge entre les pairs en faisant varier la taille de la partie de l espace métrique dont ils ont la charge en fonction de la quantité de ressources présentes, ces solutions ne supportent, soit qu un faible nombre de dimensions soit une faible attrition des pairs. 3.8 Comparaison des systèmes Les approches de recherches documentaire par mots-clefs et par similarités visent à répondre à des problématiques différentes. En effet, les approches par similarité permettent de retrouver des documents proches d un document de référence. Chaque système de ce type est donc limité à des documents partageants des propriétés communes. Ainsi, elles ne sont pas pertinentes pour un système comme le nôtre, visant à gérer n importe quel type de documents (Tableau 6.2). À l inverse, les approches par mots-clefs peuvent potentiellement gérer n importe quel type de document, mais possèdent plusieurs limites (Tableau 6.3). En effet, la descrip- 184

201 4. Systèmes P2P de travail collaboratif Figure 4 Résolution d une recherche de zone par un système P2P reposant sur la navigation dans un espace métrique. Table 4 Comparaison des systèmes de recherche documentaire par similarité Distribution Expressivité Tolérance à l attrition Equilibrage de la charge Domaine d application Réduction Limité (300 dimensionsment Faible Oui Type de docu- d espace ciblé Navigation Limité (10 dimensionsment Bonne Non Type de docu- dans l espace ciblé tion des documents ne peut se faire uniquement de façon automatique, car ces approches ne sont pertinentes que pour les documents textuels. De plus, la distribution de l index d une approche par mots-clefs est problématique, car aucune des deux approches existantes n offre des performances satisfaisantes dans le contexte d un système P2P. En effet, les approches par termes nécessitent d importantes quantités de calcul pour le pair qui effectue l intersection des listes de documents. Alors que les approches par documents nécessitent la diffusion des requêtes à l ensemble des pairs du système, ce qui est très coûteux pour un système P2P. Seules les approches par mots-clefs peuvent répondre à nos besoins, mais il est nécessaire de recourir à une description des documents par les utilisateurs et d améliorer les performances de ces systèmes sur une architecture P2P afin de les rendre utilisables [166]. 4 Systèmes P2P de travail collaboratif Les principaux systèmes de travail collaboratif basés sur le modèle P2P sont les systèmes P2P privés et les systèmes d ami à ami (Friend-to-Friend ou F2F). La principale 185

202 États de l art spécifiques aux besoins des différents contextes applicatifs considérés Table 5 Comparaison des systèmes de recherche documentaire par mots-clefs avec N le nombre de pairs, R le nombre de termes présent dans la requête, T D le nombre moyen de termes par documents et D T le nombre moyen de documents par terme Distribution Description Quantité de Calculs nécessairecation Domaine d appli- des documents messages échangé Par document Humaine O(N) O( T D N ) Tout type de documents Par document Automatique O(N) O( T D N ) Document textuel Par terme Humaine O(R) O((D T ) R ) Tout type de documents Par terme Automatique O(R) O((D T ) R ) Document textuel différence entre ces deux approches est le cloisonnement des informations sur les pairs dans le système [134]. Dans les systèmes P2P privés, les pairs forment des petits groupes d utilisateurs dans lesquels chaque membre connait l ensemble des autres membres. Ainsi, chaque pair connait l ensemble des actions effectuées par un autre pair du groupe [134]. Dans les systèmes F2F, les pairs n entretiennent des liens qu avec les pairs d utilisateurs en qui ils ont confiance [129]. Chaque pair ne connait que les pairs auxquels il est connecté et seuls ces pairs connaissent sa présence dans le système. Ainsi, seuls les pairs auxquels un pair est connecté connaissent les actions de ce pair dans le système. Ces systèmes offrent un certain nombre de fonctionnalités de bases pour supporter le travail collaboratif comme du partage de fichiers, des forums, des chat rooms, une messagerie instantanée ou encore un système de messagerie normal [134]. La principale particularité de ces systèmes est le niveau de sécurité très élevé qu ils offrent. En effet, ces systèmes sont presque indétectables et totalement opaques pour quelqu un qui lui est extérieur [129]. En marge de ces systèmes, on trouve les systèmes de gestion de révision décentralisés. En effet, si des systèmes comme Git 35 ou Mercurial 36 peuvent fonctionner de façon Ad-Hoc entre les utilisateurs, aucun d eux n implémente de mécanismes permettant d automatiser les échanges entre les utilisateurs. Ainsi, si ces systèmes peuvent supporter un fonctionnement décentralisé, ils n offrent aucune fonctionnalité pour la formation de systèmes P2P entre les utilisateurs. En fonctionnement décentralisé, ces systèmes ne sont donc adaptés que pour des groupes de deux ou trois utilisateurs. 35. Git, the fast version control system, Mercurial, 186