• Aucun résultat trouvé

Traitement de la disponibilité de données dans les RSD

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

Le problème de disponibilité de données sur les RSD est un sujet d’actualité où peu de solutions sont proposées. En effet, la majorité des RSD tels que Quasar [86], PeerSoN [2] et DECENT [41] s’intéresse à la confidentialité des données. Ils reconnaissent les problèmes de

Chapitre 5

disponibilité dans RSD, cependant, ils ne proposent pas une solution pour garantir une haute disponibilité des données dans le système. En outre, les utilisateurs des RSD ont la liberté de stocker leurs contenus sur des équipements de leurs choix. En réalité, ces équipements n’ont pas nécessairement une disponibilité élevée et ils peuvent même être défaillants. Par conséquent, assurer 24/7 disponibilité des contenus des utilisateurs stockés dans un cadre décentralisé est un défi. Dans la littérature, les solutions pour les RSD qui traitent la dispo-nibilité, présentent deux grandes classes de techniques pour assurer la disponibilité :

– nœuds stables : cette classe suppose que les équipements des utilisateurs forment une infrastructure stable et ont une disponibilité relativement élevée. Cette hypothèse res-treint le choix de l’utilisateur de son système de stockage. Par exemple, les passerelles domestiques et les décodeurs ont des capacités de stockage et ils ont un taux de dis-ponibilité plus élevé par rapport à un téléphone portable ou un ordinateur portable.

– mise en cache et réplication : les auteurs dans [87] ont montré par expérimentation

l’effet de différents paramètres sur la disponibilité de données dans les RSD. Ces pa-ramètres incluent le temps de disponibilité de l’utilisateur, le nombre de répliques et la politique de placement des répliques. Outre la disponibilité globale, les auteurs considèrent également la disponibilité du contenu seulement à leurs amis. Ils étudient différentes stratégies de réplication. Ils identifient quatre stratégies de réplication adap-tées :

1. réplication sans contraintes : cette stratégie est peu utilisée. Les répliques

sont placées pour maximiser la disponibilité d’un contenu chez les contacts les plus actifs d’un utilisateur ou de manière aléatoire sans contraintes. Leur étude montre que le placement des répliques chez les contacts les plus actifs avec une réplication de 40% donne une haute disponibilité des contenus.

2. réplication fondée sur les relations de confiance : l’utilisateur sélectionne

les répliques chez d’autres utilisateurs selon leurs relations de confiances ;

3. réplique sélectionnée par le système :les répliques sont hébergées chez des

utilisateurs selon des paramètres choisis par le fournisseur de services ;

4. réplication fondée sur les intérêts des utilisateurs : la réplication est faite

selon les intérêts des utilisateurs.

5.3.1.1 Nœuds stables

PrPl [4] et Vis-á-Vis [6] suivent ce modèle et proposent de répliquer les données des utili-sateurs sur un nombre d’utiliutili-sateurs qui peuvent servir comme un proxy quand le propriétaire de données est hors ligne.

PrPl suppose que le RS est déployé sur les passerelles domestiques, les décodeurs, les consoles de jeux ou sur des serveurs d’hébergement confiants gratuits ou payants qui sont en ligne la plupart du temps.

Vis-á-Vis utilise des serveurs virtuels fonctionnant sur l’infrastructure d’Amazon EC21 qui ont une très haute disponibilité. Cette approche évite les coûts de la bande passante et de stockage associés à la gestion des répliques.

5.3.1.2 Technique de réplication fondée sur les relations de confiance

Uniquement Safebook [3] permet à un utilisateur de créer son groupe de répliques fondé sur ses relations de confiance ou d’amitié.

5.3.1.3 Réplique sélectionnée par le système

Les données d’un utilisateur sont répliquées et cachées chez un ensemble d’utilisateurs qui fonctionnent comme un proxy quand le propriétaire de ce contenu n’est pas en ligne. Pour SuperNova et Cachet, le placement des répliques est une décision prise par le système lui-même, c’est-à-dire par les super-pairs ou les nœuds DHT, respectivement.

5.3.1.4 Réplication fondée sur les intérêts des utilisateurs

Cette stratégie est utilisée souvent par les microblogs décentralisés. Ils utilisent les modèle publier/souscrire et reproduisent les donnés des utilisateurs producteurs uniquement pour les utilisateurs souscrits. Ils suivent l’approche degossippour propager éventuellement les mises à jour des répliques. La propagation de mises à jour à long terme peut engendrer des copies

éculées chez des répliques pendant quelques instants. L’approche de gossip peut générer un

grand volume de messages sur le réseau aux moments des mises à jour par rapport aux autres approches.

Forsyth et al. [88] ont proposé aussi une approche pour la réplication et la propagation de 1. http ://aws.amazon.com/ec2-sla/

Chapitre 5

mises à jour des copies pour les microblogs décentralisés. Ils proposent d’envoyer une requête sur un microblog par chemin aléatoire sur le graphe social et mettre en cache les informations sur le chemin et les données si la recherche aboutit. La mémorisation des informations sur le chemin permet aux mises à jour futures d’être appliquées par le même chemin, ce qui permet d’avoir des répliques cohérentes.

Une étude récente faite par Asthna et al. [89] porte sur l’optimisation du nombre de

répliques et leur placement dans le contexte des microblogs en P2P. Ils proposent aussi un algorithme fondé sur le gossip pour placer les microblogs sur une partie du réseau pour as-surer une bonne disponibilité aux utilisateurs. Ce travail tente de trouver un équilibre entre le nombre d’utilisateurs où un microblog est répliqué et le nombre d’utilisateurs qui doivent être interrogés pour trouver un microblog, tout en gardant l’utilisation de la bande passante au minimum. Selon leur analyse, un microblog doit être répliqué environ 6 à 20% du nombre d’utilisateurs dans un réseau de 10.000 et 100.000 utilisateurs de microblogging respective-ment, afin d’assurer une haute disponibilité tout en exigeant moins de bande passante pour les recherches futures.

5.3.1.5 Synthèse

Le tableau ci-dessous récapitule les caractéristiques des RSD actuels. Tableau 5.1 – Disponibilité de données dans les RSD

RSD Disponibilité de données Stratégie de placement

Quasar -

-PeerSoN -

-FETHR réplication fondée sur les intérêts des utilisateurs Safebook réplication fondée sur les relations de confiance

PrPl nœuds stables

-Cuckoo réplication fondée sur les intérêts des utilisateurs

Vis-á-Vis nœuds stables

-SuperNova réplication sélectionnée par le système (super pair) Cachet réplication et mise en cache sélectionnée par le système (DHT)

Chapitre 5