COMPARAISON ANALYTIQUE DE CAP ET NETPOPPS

COMPARAISON ANALYTIQUE DE CAP ET NETPOPPS

Ce chapitre établit une comparaison analytique de nos deux contributions, présentés et analysés individuellement aux chapitres précédents. Il s’agit de CAP (Context-Aware P2p system) et NETPOPPS (NETwork Provider Oriented P2P System) 6.1 Analyse comparative et applicative des contributions Les deux contributions principales de ce mémoire, CAP et NETPOPPS ont été analysé individuellement, dans chacun des chapitres qui leur ont été respectivement dédiés. Dans ce paragraphe, nous abordons une analyse comparative et applicative des deux systèmes.  secondaires regroupant les pairs en sous-ensembles suivant une ou plusieurs caractéristiques du réseau sous-jacent (ces sous-ensembles sont dits ‘zone’ dans CAP et ‘entité’ dans NETPOPPS), et dans l’overlay correspondant à chaque sous-ensemble, il y a donc une DHT virtuelle (ou VDHT) qui se forme ; En effet, CAP est configurable et extensible. Le propriétaire d’une ressource peut définir une politique de partage de cette ressource. Chaque pair n’appartient pas nécessairement à un autre overlay que l’overlay global, et a fortiori n’appartient pas à toutes les zones du système. Chaque zone est indépendante et tout pair peut créer et initier une nouvelle zone conformément à la métrique de performance qu’il souhaite. La garantie de la découverte d’une ressource en un nombre de sauts minimal est donnée par la DHT. Mais la garantie de la sensibilité contextuelle du routage est donnée par le cloisonnement contextuel des ressources et la sémantique conséquente de l’objectId à travers la Hkey. CAP peut donc être vu comme un système cœur de réseau au-dessus duquel diverses applications peuvent être développées offrant des services à l’usager via une interface conviviale. Par exemple, l’usager pourra choisir et modifier explicitement la valeur de Hkey. Celle-ci peut aussi permettre la création explicite de groupes de communication sécurisés ou avec une qualité de service privilégiée. Ces groupes seront alors autogérés sans qu’il y ait besoin d’une entité de contrôle pour en vérifier l’accès. Aussi grâce à la Hkey, CAP peut être aussi adapté pour router des requêtes complexes qui s’exécuteront en parallèle dans plusieurs zones.

Quant à NETPOPPS, il simplifie considérablement la gestion des identifiants. Chaque élément a ses identifiants en relation mathématique simple entre eux. Et un objet peut même garder un même et seul identifiant dans tout le système, si les différents espaces d’identification du système sont de même taille. Ce qui améliore encore plus les performances (diminue les temps de latence et recherche d’un objet, et donc de réponse). Mais dans NETPOPPS, le cloisonnement des ressources est conforme aux intérêts de l’opérateur du réseau. Un usager ne peut pas décider de la création d’un overlay secondaire, donc non plus d’un groupe de communication, surtout avec des usagers d’autres BEs. La structure du système est fixée par l’opérateur qui gère le réseau de façon quasi-rigide, que seule la renégociation des accords inter-opérateur peut modifier (ou la politique intra-opérateur dans le cas où un opérateur gère plusieurs BEs).  De plus, à travers le nœud de contrôle, NETPOPPS offre à l’opérateur du réseau la possibilité d’exercer un contrôle d’accès sur les pairs utilisant ses réseaux ou de leur offrir ses services propriétaires (e.g. des services privilégiés et/ou payant). La porte est ainsi large ouverte à des services commerciaux, des mesures statistiques, etc.

NETPOPPS, comme la solution de service intermédiaire (oracle service) [AFS07] et comme P4P [XKS+07], met en avant le rôle qu’un opérateur de réseau peut prendre dans l’adéquation d’un réseau P2P à la topologie sous-jacente, l’optimisation du trafic P2P et des différents coûts, et la performance des applications. Cependant, les opérateurs de réseaux,  notamment les ISPs considèrent généralement la topologie des réseaux qu’ils contrôlent comme étant des informations confidentielles [MG08]. Par conséquent, pour réussir à être adopté à très large échelle, une solution de sensibilisation du trafic P2P à la topologie sous-jacente doit fournir une méthode qui aide les applications dans la sélection des pairs sans qu’il y ait besoin de divulguer explicitement la topologie du réseau sous-jacent. Dans cette perspective, CAP est prometteur, en tant que système générique, flexible et orienté utilisateur. Toutefois, comme dans tout domaine de recherche applicative, une large adoption à très grande échelle d’un système P2P sensible à la structure sous-jacente ne verra probablement pas le jour sans un accord entre les principaux acteurs sur une solution commune basée sur des standards libres de droit [MG08].