Traitement de l’expressivité dans les systèmes publier/souscrire basés DHT

Télécharger le fichier pdf d’un mémoire de fin d’études

Historique des RS

Avec l’émergence du Web 2.0, les utilisateurs finaux sont placés au cœur de diverses technologies Web, qui ont tendance à remodeler l’avenir du WWW en termes de structure, conception et utilité. Dans ce contexte, les RS en ligne apparaissent comme un nouveau type d’application sur Internet, qui peut être considéré comme une extension naturelle des applications Web établissant et gérant des relations explicites entre les utilisateurs pour la majorité des RS. Plus précisément, un RS se compose d’utilisateurs qui communiquent les uns avec les autres en ligne par diverses manières. Les RS ont eu beaucoup de succès ces dernières années et le nombre d’utilisateurs connectés sur ces réseaux augmente d’une façon exponentielle. Aujourd’hui, nous témoignons la croissance rapide d’une grande variété de RS, qui publient les contenus générés ou modifiés par les utilisateurs et qui permettent aux utilisateurs d’annoter le contenu publié par des étiquettes, des commentaires et des recommandations [1].

Le premier RS le plus connu, nommé SixDegrees.com, est lancé en 1997. L’origine de son nom provient de la théorie de six degrés de séparation. Cette théorie évoque la possibilité que toute personne de l’univers peut être reliée à n’importe quelle autre personne, à tra-vers une chaîne du réseau relationnel entre elles comprenant au plus cinq autres maillons intermédiaires. À travers SixDegrees.com, les utilisateurs peuvent créer leurs profils, avoir un groupe d’amis et fournir des informations à leur communauté. Bien que ce réseau ait attiré des millions d’utilisateurs, il n’a pas pu évoluer et a été stoppé en 2000. Le fondateur de SixDegrees.com estime qu’il était en avance sur son temps. Depuis 2003, nous avons assisté à une révolution et une assimilation de sites de RS qui ont établi la plupart des sites les plus populaires de nos jours. Cette révolution a apporté un changement radical sur l’activité des utilisateurs, leurs cultures et le domaine de la recherche sur le WWW [22]. La Figure 1.1 présente l’évolution des RS au cours de la dernière décennie.

Selon les dernières recherches de Nielson 1 faites en 2010, les sites des RS et des blogs sont classés comme la quatrième activité la plus populaire sur Internet. En eﬀet, plus des deux tiers de la population mondiale connectée participent aux RS et aux blogs. En outre, les médias sociaux ont pris de l’avance sur l’e-mail dans le classement des activités les plus populaires en ligne. Une autre constatation intéressante est que les temps de session sur les RS et les blogs atteint 10% de tout le temps passé en navigation. Ces statistiques suggèrent que les RS sont devenus un élément fondamental sur le Web à travers le monde.

Le progrès important apporté aux sites de RS comme Facebook, Myspace, Flickr, Lin-kedIn et YouTube, et la principale force motrice de leur succès, sont expliqués par le fait que les sites de RS mettent l’accent sur les intérêts des utilisateurs pour développer leurs services. Par conséquent, l’objectif principal des RS est de fournir des fonctionnalités de réseautage social comme un service de base pour une variété d’applications et de services de haut niveau. En outre, les RS en ligne sont à l’issu de nouveaux problèmes intéressants et des défis pour la recherche dans un environnement qui devient de plus en plus complexe [23, 24]. Aujourd’hui, les RS sont devenus l’objet de nombreuses entreprises en démarrage, oﬀrant aux utilisateurs la possibilité de créer, rechercher et gérer leurs propres communautés de RS.

Architecture de base des RS

Une architecture de référence pour les RS déployés sur Internet est présentée dans la Figure 1.2. Le système entier est formé par les couches suivantes situées au dessus de la couche hardware et la couche du système d’exploitation :

– Data Storage Layer : cette couche est formée par deux composants principaux : le Storage Manager qui est chargé de stocker eﬃcacement les informations des graphes sociaux en assurant la manutention de charges croissantes de bases de données. Ceci est habituellement réalisé en adoptant une mémoire cache distribuée. Le deuxième composant est appelé Data Store. Il comprend les éléments de stockage qui mémorisent des informations sur le service du RS. Ces Data Stores peuvent être des bases de données Multimédia, des bases de données des Profils utilisateurs, etc.

– Content Management Layer : cette couche est responsable de trois tâches princi-pales. Tout d’abord, il s’agit de collecter des informations sociales provenant des autres RS pour les incorporer dans un Content Aggregator qui collecte et organise les contenus reçus des médias sociaux et les distribue aussi vers les autres RS. Deuxièmement, il facilite la maintenance et la récupération du graphe présentant le contenu social à tra-vers le Data Manager. La troisième tâche Access Control Manager consiste à contrôler l’accès des utilisateurs par la création et la maintenance du schéma de contrôle d’accès.

– Application Layer : chaque site Web de RS supporte plusieurs services implantés par la couche application, comme la recherche, le flux d’actualités, les accès mobiles, etc. Les services de cette couche communiquent avec le Data Manager et l’Access Control Manager dans le but d’analyser et de gérer le graphe du contenu social. Les applications sont fournies aux utilisateurs à travers l’Application Manager. L’Application Manager facilite l’interaction de l’utilisateur à travers un ensemble d’API. Ce composant contient aussi un Service Framework pour le développement de services évolutifs franchissant les obstacles linguistiques.

Les utilisateurs interagissent avec une plateforme de RS via des requêtes HTTP. Chaque utilisateur peut soit être inscrit comme utilisateur autorisé ou être anonyme. Les utilisateurs enregistrés ont généralement plus de droits que ceux anonymes (pour commenter des contenus publiés, télécharger des éléments multimédias, etc.).

Le module de contrôle d’accès est chargé de traiter les paramètres de confidentialité et de sécurité des utilisateurs des RS. La plupart des recherches dans le domaine de confidentialité et sécurité des RS se sont concentrées sur le développement des techniques de protection des renseignements personnels en fournissant des solutions à des problématiques telles que la propriété des informations personnelles et la protection de la vie privée [25, 26, 27, 28, 29].

Chaque plateforme de RS se compose de plusieurs serveurs d’applications, qui oﬀrent un ensemble de services et d’API. Un utilisateur envoie une requête à la plateforme du RS, qui la transmet au serveur d’application approprié. Un équilibreur de charge est responsable de surveiller les serveurs d’applications de RS, d’équilibrer la charge des requêtes, de protéger le système contre les pannes par relais entre ces serveurs, et de transmettre les requêtes aux serveurs d’applications [1]. Quant à la distribution de contenu, des serveurs de cache accé-lèrent les applications Web dynamiques en allégeant la charge des serveurs d’applications.

De plus, les RS présentent des exigences de Qualité de Service (QdS) importantes par rapport aux applications Web traditionnelles. Parmi les principales diﬀérences entre les applications Web et les plates-formes de RS, nous citons les relations et la confiance entre les utilisa-teurs, qui changent au fil du temps. Ce comportement dicte la conception d’algorithmes de placement des données, de réplication et de distribution dans les RS. Une autre diﬀérence im-portante est que les RS impliquent un grand nombre de fichiers de petites tailles qui doivent être fréquemment consultés et mis à jour par un grand nombre d’utilisateurs et impliquent la propagation des mises à jour de ces fichiers pour garantir la cohérence des données. Pour améliorer davantage les performances du système, les plates-formes de RS distribuent leurs contenus sur les réseaux de distribution de contenu (Content Distribution Networks) comme Akamai [30], ou sur des infrastructures de Cloud. Avec un réseau de diﬀusion de contenu (Content Delivery Network (CDN)) [31], les requêtes des utilisateurs sont automatiquement acheminées aux serveurs périphériques, où les contenus des serveurs d’origine sont répliqués. Généralement, ces serveurs sont connectés à Internet à travers des dorsales Internet.

Enfin, les Data Stores des RS peuvent être centralisés ou distribués au travers de multiples domaines administratifs. Les RS centralisés soulèvent des inquiétudes concernant la protec-tion des informations personnelles et la scalabilité.

Classification des RS

Une étude exhaustive des aspects des RS existants nous permet de déterminer la classifi-cation présentée dans la Figure 1.3 [1]. Nous retrouvons quatre grandes branches pour décrire un tel réseau social. La première branche couvre le champ d’application des RS en termes

Du point de vue champ d’application, les RS peuvent être classifiés en deux catégories :

– RS de « loisirs » : la plupart des RS sont des RS de loisirs. Leur rôle est le partage des loisirs qui peuvent être des jeux, des informations, des photos, des vidéos ou des savoirs dans tous les domaines de la vie courante entre des communautés d’amis. Les plus populaires de cette catégorie sont Facebook, Myspace, Hi5 et Flickr.

– RS d’ « Aﬀaires » : leur rôle est de relier les professionnels du monde entier pour les rendre plus interactifs et productifs. Grâce au RS d’aﬀaires, les utilisateurs enregistrés

créent des profils qui résument leurs expertises et leurs activités professionnelles. Les RS indicatifs dans cette catégorie sont LinkedIn et Xing.

La deuxième dimension présentée par cette taxonomie est le modèle de données (Data Model) suivi par les fournisseurs de RS. Ici, nous identifions les catégories suivantes :

– Data Model centralisé : les données des RS centralisés sont stockées entièrement sur une proximité physique qui peut être un Cluster ou un Data Center. Ceci concentre les données des utilisateurs sous un seul domaine administratif. La plupart des RS s’appuient sur le stockage et la fonctionnalité centralisés vu que leur souci est de soulever des préoccupations concernant la protection de la vie privée des utilisateurs et leur capacité de supporter une base croissante d’utilisateurs et d’applications.

– Data Model décentralisé : les données des RS décentralisés sont distribuées à tra- vers multiples domaines administratifs [2, 32]. Les serveurs d’applications s’exécutent sur les machines de bureau (les pairs) appartenant aux utilisateurs. En général, l’hé-bergement de données personnelles sur les pairs est plus sécurisé que de déléguer leur contrôle à un fournisseur de services tiers. En outre, ce modèle est moins cher que l’ac-quisition d’équipements centralisés dédiés. L’inconvénient majeur de cette approche est que les pairs ne sont pas disponibles en permanence. Les pairs sont sujets à des défaillances, des redémarrages, des power-oﬀs, des déconnexions de réseau, etc. [33]. Une discussion plus détaillée sur les RS décentralisés sera donnée dans la section 1.9. La troisième branche de cette classification présente la plateforme d’exécution des RS.

Nous identifions les deux classes suivantes :

– RS fondé sur une application Web : les serveurs d’applications hébergent les sites Web qui oﬀrent un ensemble de services et API. Dans un tel RS, l’équilibreur de charge équilibre la charge des requêtes, gère tout relais et transmet les demandes aux serveurs d’applications appropriées. Dans les régimes fondés sur le Web, la plupart des services de RS sont gratuits pour les utilisateurs.

– RS fondé sur le Cloud : les serveurs d’applications sont hébergés par une infra-structure informatique utilitaire telle qu’Amazon Elastic Compute Cloud (EC2). Dans un tel RS, chaque utilisateur stocke ses propres données sur une instance de machine virtuelle personnelle, appelée Virtual Server. Les principaux avantages de ce RS sont sa haute disponibilité et la sécurité des informations puisque chaque utilisateur conserve ses données personnelles dans un serveur virtuel résidant dans un environnement de Cloud Computing. En outre, les RS de Cloud Computing sont généralement intégrés aux infrastructures CDN (par exemple, Amazon Cloud Front intègré avec Amazon EC2). Ceci résulte en une distribution de contenus aux utilisateurs finaux avec une faible latence et une vitesse de transfert très élevée. D’autre part, l’hébergement de données dans un Cloud augmente les coûts dus à l’utilisation d’une infrastructure commerciale.

Finalement, la taxonomie couvre le réseau relationnel formé par le RS qui distingue ces deux classes :

– RS orienté utilisateur (relationnel) : les RS de cette catégorie mettent en valeur les relations sociales. Ainsi, le partage de contenus se fait principalement entre les utilisateurs qui appartiennent à la même communauté. Les RS de cette catégorie sont Facebook, MySpace et LinkedIn.

– RS fondé sur le contenu (thématique) : le réseau des utilisateurs n’est pas déterminé par les relations sociales sous-jacentes, mais par les intérêts communs entre les utilisateurs. Les RS de cette catégorie sont les blogs, les forums et les services de partage (par exemple, YouTube).

RS populaires

Cette section détaille les RS existants et les plus populaires. Pour chaque plateforme de RS, nous présentons un bref historique, son architecture et son modèle économique (Business Model) pour enfin tirer les points forts et faibles des diﬀérents RS déployés sur Internet.

Facebook

Histoire et portée : Facebook 2 a été fondé par Mark Zuckerberg quand il était étudiant en psychologie à l’Université de Harvard. En Février 2004, Zuckerberg a lancé « Facebook » ; le nom a été tiré des albums photo regroupant les photos profils de tous les élèves, prises en début de l’année universitaire. Ces albums sont appelés « trombinoscopes » en français et « Facebooks » en anglais. À sa création, il était un RS réservé aux élèves de l’Université de Harvard. En septembre 2006, Facebook a été étendu au-delà des établissements d’enseigne-ment et s’est ouvert au monde entier. Aujourd’hui, Facebook est l’une des destinations en ligne les plus populaires avec plus de 300 millions d’abonnés, qui passent en moyenne 20 minutes par jour sur ce site et qui contribuent par 4 milliards d’éléments d’information, 850 millions de photos et 8 millions de vidéos chaque mois. Il a été dédié initialement à une fonc-tion de loisirs plutôt qu’à un usage professionnel. Il est à la fois orienté contenu et orienté utilisateur. Les utilisateurs créent leurs réseaux par la connaissance d’un groupe d’amis et ils peuvent aussi créer des réseaux fondés sur des intérêts communs. Pour un groupe fondé sur l’intérêt commun, les autres utilisateurs doivent être inscris à ce groupe et ne peuvent profiter que des informations partagées par le propriétaire du groupe. Pour un utilisateur inscrit sur Facebook, il peut ajouter des amis et leur envoyer des messages, partager des photos, vidéos, liens, mettre à jour son profil personnel et consulter le partage de ses amis.

Lors du partage de données, le propriétaire peut définir leur visibilité. Un utilisateur de Fa-cebook peut consulter les données partagées par son groupe d’amis sans savoir le contenu auparavant s’il l’intéresse ou non. Ce type de partage est aussi limité souvent aux groupes d’amis.

Conception architecturale : l’architecture du modèle de données de Facebook est centralisée et fondée sur un modèle hiérarchique d’application Web en PHP avec une couche de mise en cache de données. La couche de mise en cache est fournie via le logiciel open source Memcached. En ce qui concerne la couche d’application (Application Layer), Facebook utilise un framework RPC (Remote Procedure Call) open source d’Apache appelé Thrift, qui est utilisé pour RPC en temps réel et avec une faible latence et pour le stockage persistant de données structurées provenant d’une variété d’applications, telles que la recherche, le fil d’actualité, etc. Le langage RPC est influencé par l’IDL de CORBA. Facebook soutient divers services de back-end qui utilisent les frameworks Hadoop, Scribe et Hive. Quant au Data Storage Layer, les données telles que les photos, les statuts et les commentaires sont périodiquement stockées dans des dépôts centraux et des bases de données de catégorie NoSQL (Cassandra 3). Concernant la plateforme d’exécution, les serveurs d’applications de Facebook s’exécutent sur les infrastructures fondées sur des applications Web et sur le Cloud Computing (Amazon EC2).

Modèle économique : puisque l’inscription à Facebook est gratuite, son modèle éco-nomique dépend de la publicité. Ce modèle économique est fondé sur le principe que les inscriptions gratuites construisent un public ayant des intérêts et des besoins distincts que les annonceurs paieront pour l’atteindre. Facebook prend en charge deux politiques de pu-blicité : le Pay for Clicks permet aux annonceurs de préciser un certain montant qu’ils sont prêts à payer chaque fois qu’un utilisateur clique sur leur annonce, alors que, le Pay for Views permet aux annonceurs de spécifier combien ils sont prêts à payer pour 1000 vues de leur annonce. En outre, Facebook oﬀre la possibilité de cibler les annonces à des groupes d’utilisateurs spécifiques. Cela permet aux annonceurs de rédiger des textes d’annonce plus personnalisés, rendant leurs annonces plus attrayantes pour les utilisateurs qu’ils atteignent. Facebook prend en charge plusieurs options de ciblage telles que la localisation, les anni-versaires, les préférences et les intérêts. Facebook a connu une réussite très importante qui est la suivante : « Pendant 12 mois, CM Photographics a généré près de 40 milles dollars de revenus directement d’un investissement publicitaire de 600 dollars sur Facebook. Parmi les utilisateurs de Facebook qui ont été dirigés vers le site Web de CM Photographics suite aux annonces, 60% sont devenus des prospects qualifiés ».

MySpace

Histoire et portée : MySpace 4 est fait essentiellement pour le loisir. Il a été déve-loppé en Août 2003 par les employés d’eUniverse qui ont cherché à imiter les caractéristiques populaires du RS Friendster. Les premiers utilisateurs de MySpace étaient des employés d’eU-niverse. En Juillet 2005, MySpace a été vendu pour 580 millions dollars à News Corporation de Rupert Murdoch. MySpace est devenu le site le plus populaire de RS aux États-Unis en Juin 2006. Aujourd’hui, MySpace est l’un des RS ayant une croissance la plus rapide couvrant 300 millions d’utilisateurs. C’est un RS orienté utilisateur, où chaque utilisateur enregistré peut partager entre amis son profil personnel, ses photos, ses vidéos, ses liens, etc. L’utilisateur peut également utiliser des jeux et mettre à jour son profil personnel pour informer ses amis de ses actualités. MySpace gère également la gestion d’évènements, tels que des lancements de produits et d’albums pour les grandes étiquettes qui fournissent des flux de revenus supplémentaires.

Conception architecturale : l’architecture de MySpace est centralisée et fondée sur ASP.Net 2.0 avec une couche de mise en cache de données et d’un ensemble de composants de services. Plus précisément, MySpace est composé de plus de 500 serveurs Web exécutant Windows 2003 / IIS 6.0 / APS.NET. Les Data Stores de MySpace se composent de 1200 serveurs de cache supportant Windows 2003 64-bit avec 16 Go d’objets mis en cache dans la mémoire RAM, et 500 serveurs de base de données exécutant Windows 64 bits et SQL Server 2005. Comme Facebook, la couche de mise en cache est fournie via le logiciel open source Memcached. Pour le Data Storage Layer, les données sont stockées dans des dépôts centraux et des bases de données relationnelles. Pour la plateforme d’exécution, les serveurs d’applications de MySpace s’exécutent sur des applications Web et sur le Cloud Computing (Amazon EC2).

Modèle économique : l’abonnement à MySpace est également gratuit. Par conséquent, le modèle économique de MySpace est également tributaire de la publicité. De même que Facebook, MySpace utilise deux politiques publicitaires : Pay for Clicks et Pay for Views.

Pour plus de pertinence, MySpace utilise un ensemble riche de données démographiques et comportementales. Ceci permet aux annonceurs de cibler leur public en se basant sur des qualités, des intérêts et des activités. Tous les services sont oﬀerts gratuitement aux utilisateurs. Les utilisateurs peuvent créer de nouveaux contenus pour attirer, à leur tour, de nouveaux utilisateurs. Cela a encouragé plusieurs entreprises à utiliser la plateforme MySpace pour la publicité de leurs produits.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction Générale
1 État de l’art : Réseaux Sociaux (RS)
1.1 Introduction
1.2 Définition d’un RS
1.3 Services offerts par les RS
1.4 Historique des RS
1.5 Architecture de base des RS
1.6 Classification des RS
1.7 RS populaires
1.7.1 Facebook
1.7.2 MySpace
1.7.3 Hi5
1.7.4 Flickr
1.7.5 LinkedIn
1.7.6 Twitter
1.7.7 YouTube
1.7.8 Synthèse
1.8 Motivation pour le développement d’un réseau social distribué (RSD)
1.9 RSD académiques
1.9.1 PeerSoN
1.9.2 Safebook
1.9.3 PrPl
1.9.4 SuperNova
1.9.5 Vis-á-Vis
1.9.6 Cachet
1.9.7 Microblogs en P2P
1.9.7.1 FETHR
1.9.7.2 Cuckoo
1.9.8 Synthèse
1.10 Conclusion
2 MULUS : un RSD pour une consommation sélective de contenus composites
2.1 Introduction
2.2 Concepts de base
2.2.1 Système P2P
2.2.1.1 Définition d’un système pair-à-pair
2.2.1.2 Caractéristiques des systèmes P2P
2.2.1.3 Classifications des systèmes P2P
2.2.2 Caractéristiques des tables de hachage distribuées (DHT)
2.2.3 Système publier/souscrire
2.2.3.1 Définition
2.2.3.2 Architecture
2.2.3.3 Filtrage dans les systèmes publier/souscrire
2.2.3.4 Caractéristiques d’un système publier/souscrire
2.2.3.5 Système publier/souscrire basé DHT : Scribe
2.2.4 Aspect sémantique : ontologie
2.3 Vue d’ensemble de l’approche proposée
2.3.1 Présentation générale de la plateforme MULUS
2.3.2 Architecture de MULUS
2.4 Caractéristiques de MULUS
2.4.1 Scalabilité
2.4.2 Consommation sélective des contenus partagés
2.4.3 Composition des contenus partagés
2.4.4 Traitement du dynamisme fort des utilisateurs
2.5 Conclusion
3 Traitement de la sémantique dans MULUS
3.1 Introduction
3.2 État de l’art : traitement de la sémantique
3.2.1 Traitement de l’expressivité dans les systèmes publier/souscrire basés DHT
3.2.2 Traitement de la sémantique dans les systèmes publier/souscrire centralisés et hiérarchiques
3.2.3 Synthèse
3.3 Concepts de base
3.3.1 Définition et objectifs d’une ontologie
3.3.2 Composition d’une ontologie
3.3.3 Langage de modélisation d’une ontologie
3.3.4 Langage SWRL
3.4 Traitement de la sémantique dans MULUS
3.4.1 Architecture du Home Box Entity (HBE)
3.4.1.1 Home Repository Manager (HRM)
3.4.1.2 Global Topic List Manager (GTLM)
3.4.1.3 Global Topic Directory Manager (GTDM)
3.4.1.4 Device Manager (DM)
3.4.2 Codage sémantique
3.4.2.1 Définition de l’ontologie de domaine
3.4.2.2 Indexation de l’ontologie de domaine avec les nombres premiers
3.4.2.3 Mise à jour des index de l’ontologie de domaine
3.4.3 Communication entre les HBE
3.4.3.1 Phase de souscription
3.4.3.2 Phase de publication
3.4.3.3 Mise à jour de l’ontologie de domaine
3.5 Exemple de scénario : partage de données multimédias
3.6 Évaluation de performance : réduction du trafic
3.7 Conclusion
4 Composition d’évènements sur MULUS
4.1 Introduction
4.2 Concepts de base
4.2.1 Définition d’un évènement
4.2.2 Évènement primitif
4.2.3 Évènement composite
4.2.4 Souscription composite
4.3 Problématique
4.4 État de l’art : composition d’évènements dans les systèmes publier/souscrire
4.4.1 Composition d’évènements dans les systèmes publier/souscrire centralisés
4.4.1.1 Système RUBCES
4.4.1.2 Détection des évènements composites par les automates à états finis (FSA)
4.4.1.3 Composition d’évènements dans un système de communication multimédia
4.4.1.4 PSware pour les réseaux de capteurs sans fil
4.4.2 Détection d’évènements composites avec des FSA distribués
4.4.3 Composition d’évènements sur les systèmes publier/souscrire basés DHT
4.4.4 Synthèse
4.5 CECube : filtrage des évènements composites dans MULUS
4.5.1 Relations de compositions des évènements
4.5.2 Modélisation et indexation des évènements composites
4.5.2.1 Modèle représentatif d’un évènement composite
4.5.2.2 Indexation des évènements atomiques et composites
4.5.3 Démarche proposée pour le matching des évènements composites
4.5.3.1 Phase de souscription
4.5.3.2 Phase de publication
4.6 Évaluation des performances
4.6.1 Réduction de trafic grâce à la composition d’évènements
4.6.2 Comparaison entre modèles de souscriptions composites : avec intersections et sans intersections
4.6.3 Étude de la scalabilité de MULUS
4.6.4 Comparaison avec JTangCSPS
4.7 Conclusion
5 Disponibilité des contenus dans MULUS
5.1 Introduction
5.2 Concepts de base
5.2.1 Placement de données sur DHT
5.2.2 Définition de churn
5.2.3 Problème de churn
5.2.4 Architecture des systèmes P2P fondés sur DHT
5.3 État de l’art : traitement de la disponibilité de données
5.3.1 Traitement de la disponibilité de données dans les RSD
5.3.1.1 Nœuds stables
5.3.1.2 Technique de réplication fondée sur les relations de confiance
5.3.1.3 Réplique sélectionnée par le système
5.3.1.4 Réplication fondée sur les intérêts des utilisateurs
5.3.1.5 Synthèse
5.3.2 Traitement de la disponibilité de données dans les systèmes publier/- souscrire basés DHT
5.3.3 Traitement de la disponibilité de données dans les réseaux P2P structurés128
5.3.3.1 Réplication à base de leafset ou successeurs
5.3.3.2 Réplication à base de clés multiples
5.3.3.3 Protocole de maintenance
5.4 Traitement de la disponibilité de données dans MULUS
5.4.1 Complémentaires des digits de poids forts
5.4.2 Réplication selon la disponibilité des nœuds
5.5 Évaluation des performances
5.5.1 Évaluation de la première approche
5.5.2 Comparaison entre les deux stratégies de réplication
5.5.2.1 Métriques de test
5.5.2.2 Comparaison entre les deux stratégies de réplication
5.6 Conclusion
Conclusion générale
Liste des Publications
Bibliographie