P2P

Une application est dite Pair à Pair ( P2P Peer To Peer ) si elle met en relation des programmes de même nature sans intermédiaire. La grande caractéristique des applications Peer To Peer est que chaque participant (peer ou pair) joue à la fois le rôle de client et de serveur. Il va donc à la fois proposer et consommer des « services » .

P2P (Document au format Word)

 

Sommaire.. 1

Introduction.. 2

Définition.. 2

Exemples d’Utilisations du P2P. 2

Le partage de fichiers. 2

Communication et collaboration. 2

Pourquoi utiliser des applications P2P ?. 3

Fiabilité et scalabilité. 3

Performances. 3

Topologies P2P.. 4

P2P Centralisés. 4

Avantages. 4

Inconvénients. 4

P2P « Purs » non structurés. 5

Exemple. 5

Avantages. 5

Inconvénients. 6

Exemple de Gnutella. 6

P2P  Hybrides ou « super-peers ». 8

P2P « Structuré » (DHT Distribued hashed table) 9

Exemple de Chord. 9

Avantages. 10

Inconvénients. 10

P2P Sémantique.. 10

Routing Indices. 10

Semantic overlays networks (SON) 11

Windows Vista et le P2P.. 13

Introduction.. 13

Architecture.. 13

Network Addressing (NAT) et FireWalls. 13

IPV6. 14

Teredo (RFC 4380) 15

PNRP. 15

PNRP Clouds. 16

Les Noms des Pairs et le PNRP ID.. 16

PNRP Résolution. 17

PNRP Cache. 17

Graphing.. 18

Optimisation des connexions entre nœuds. 18

Connexion au graphe. 19

Déconnexion du graphe. 19

Détection et réparation d’une partition dans le graphe. 19

Exemple : 19

PeerChannel et WCF ( Windows communication Fundation ) 21

Applications utilisant la technologie P2P Vista.. 22

Radius. 22

Conclusion.. 23

Projets P2P. 23

Bibliographie.. 24


 

Introduction

Définition

Une application est dite Pair à Pair ( P2P Peer To Peer ) si elle met en relation des programmes de même nature sans intermédiaire. La grande caractéristique des applications Peer To Peer est que chaque participant (peer ou pair) joue à la fois le rôle de client et de serveur. Il va donc à la fois proposer et consommer des « services » . 

Exemples d’Utilisations du P2P

 

Le modèle P2P n’est pas adapté pour toutes les utilisations. Par exemple une application d’e-commerce ne va pas déporter son module de prise de commande sur ses clients. Par contre, certaines applications  peuvent tirer d’énormes avantages dans l’utilisation de cette technologie. Afin de mieux comprendre ce qu’est le P2P,  nous allons citer quelques unes de ses utilisations. On peut ainsi citer :

 

Le partage de fichiers 

Partage privé

Si un utilisateur voulait partager des fichiers volumineux ( par exemple des photos de vacances ) avec ses proches. Il devait jusqu'à présent les télécharger sur son site web où son hébergeur pouvait limiter son espace. Pour ce modèle, il est également assez difficile de restreindre l’accès aux photos à quelques utilisateurs uniquement.  Ces fonctionnalités peuvent être assurées par des applications P2P telles que Qnext ou TribalWeb.

Diffusion multiple

Dans le cas ou des fichiers doivent être diffusés auprès d’un grand nombre de personnes (par exemple diffusion d’une émission vidéo ou audio), une autre application P2P est adaptée : BitTorrent.  Le protocole Bit Torrent découpe ainsi un fichier en plusieurs morceaux. Chaque utilisateur téléchargent le fichier va contacter le « tracker » pour obtenir la liste de toutes les machines ayant déjà téléchargé un des morceaux du fichier.  Plus un fichier est téléchargé et plus il y a donc de sources disponibles. L’inconvénient de Bit Torrent est que les fichiers ayant une certaines ancienneté ou une popularité faible vont avoir moins de sources voire même une disparition du réseau.

Sauvegarde coopérative.

La sauvegarde croisée est une application intéressante du pair à pair qui consiste à sauvegarder ses données sur l'espace disque disponible des autres. Pour assurer un équilibre, le système doit procéder par échanges : si A stocke une quantité x pour B, alors il pourra aussi stocker x chez B. (Freenet, LeanOnMe)

 

Communication et collaboration

Les applications P2P sont très adaptés pour toutes les applications nécessitant une communication entre pairs. Cette communication peut être audio ( Skype )  ou  par simple message texte ( chat et plateforme Jabber)  ou permettre aux utilisateurs de jouer  ensemble

 ( jeux multi joueurs ) ou même de travailler ensemble (plateforme de travail collaboratif GROOVE).

 

Pourquoi utiliser des applications P2P ?

 

Par rapport à un modèle client serveur, le modèle P2P présente plusieurs avantages :

 

Fiabilité et scalabilité( capacité d’évolution),

 

Il n’y a pas de goulet d’étranglement. Dans un modèle client serveur, si le serveur n’a pas assez de ressource processeur ou si sa bande passante réseau est insuffisante, ce sont l’ensemble des peers qui sont affectés. De plus, l’ensemble de l’application s’effondre dans le cas ou le serveur central s’arrête. Le partage des ressources en P2P est beaucoup plus distribué, chaque Peer servant à la fois de serveur et de client et permettant ainsi de partager la charge réseau et ressource processeur. 

Performances

 

Les ressources accédées sont généralement locales et non plus distantes. Par exemple, dans le cas de partage de fichier


Topologies P2P

P2P Centralisés

Ce type de topologie est servie par un serveur central qui sert d’annuaire. Les pairs se connectent au serveur central en donnant leur liste de ressources partagées et en demandant une ressource particulière. Le serveur renvoie une liste de pairs contenant la ressources demandée. C’est l’architecture utilisé par le logiciel NAPSTER.

 

Figure 1 :  P2P Centralisé

Avantages

  • Simplicité : pas de soucis de connexion au bon serveur.
  • La recherche de document est facilitée. Le serveur maintient en effet un index des ressources.
  • Trafic réseau réduit. Les pairs ne communiquent entre eux que s’ils ont quelque chose à échanger.

Inconvénients

  • Robustesse : il suffit de supprimer le serveur pour que l'intégralité du réseau soit inactif. Il est cependant possible de réduire cet inconvénient par la mise en place de clusters de serveurs ou alors de serveurs répliqués.
  • Aucun anonymat n'est possible, puisque chaque utilisateur est identifié sur le serveur.

 

P2P « Purs » non structurés

 

Ici, plus de serveur centralisé. Tous les pairs sont à la fois client et serveur. Ce qui pose plusieurs problèmes :

  • Découverte de la topologie du réseau.
  • Recherche et récupération de l’information.

 

Chaque pair  peut communiquer directement avec l’ensemble

des ses voisins. Afin de rejoindre le réseau, un participant doit connaître au moins un membre qui deviendra son premier voisin. Cela est fait soit par l’intermédiaire de pairs notoirement connus ou par une requête broadcastée sur le réseau pour trouver les pairs déjà connectés.  Le routage des requêtes et des réponses se fait par inondation. Chaque nœud retransmet chaque requête à ses voisins, l’évalue et y répond si possible. La durée de vie d’une requête est limitée au nombre de sauts maximum. Il peut être possible que le nombre de saut maximum soit inférieur au nombre de sauts requis, auquel cas, la requête n’aboutit pas.

Exemple

Figure 2 : P2P non structuré.

 

Le client A se connecte sur le réseau, mais il ne connaît pas la topologie du réseau.

Pour connaître les autres membres du réseau, A va "broadcaster" une demande

d’identification des noeuds du réseau.

Les noeuds recevant la demande vont à leur tour la répercuter sur tous les noeuds voisins

et ainsi de suite (comme les noeuds B, C et D).

Lorsque que la trame est reçue et identifiée par un autre client, le noeud renvoie une trame

d’identification à A.

Ainsi A va peu à peu pouvoir identifier tous les noeuds du réseau et se créer un annuaire.

Avantages

  • La taille d'un tel réseau est théoriquement infinie. IL n’y a pas de contraintes sur les ressources d’un serveur central.
  • Anonymat
  • Tolérance aux pannes (grand nombre de noeuds pouvant répliquer les mêmes données)
  • Adaptabilité (connexion et déconnection des pairs sans conséquences)

Inconvénients

  • Gros consommateur de Bande passante.
  • Pas de garantie de succès, ni d'estimation de la durée des requêtes.
  • Pas de sécurité, ni de réputation (pas de notion de qualité des pairs, ni des données fournies).

Exemple de Gnutella

http://rfc-gnutella.sourceforge.net/

 

Types de requête

 

Types

Description

Information

Ping

Annonce la disponibilité, et lance une recherche de pair

Vide

Pong

Réponse à un ping

IP et N° de port. Nombre et taille des fichiers partagés

Query

Requête

Bande passante minimum demandée. Critères de recherche

QueryHit

Réponse à query si on possède la ressource

IP + N° de port + Bande Passante. Nombre de réponses + descripteur

Push

Demande de téléchargement pour les pairs derrière un firewall

IP du pair ; index du fichier demandé. Adresse IP + N° de port où envoyer le fichier

 

Figure 3 : Les requêtes Gnutella

 

Ajout d'un noeud

A souhaite se connecter au réseau Gnutella.

A va émettre un message Ping ( trait rouge sur la figure ) soit par broadcast soit à une liste de pairs connus.

 

B reçoit la requête Ping de A.

B répond à A en lui envoyant une requête Pong.

B transfère le ping de A aux pairs qu’il connaît ( C et D )

 

Si le nombre de sauts maximum n’a pas été atteint, alors C et D répètent les mêmes opérations.

Figure 4 : Ajout d'un noeud dans Gnutella

 

A la fin de l’opération A va connaître les noeuds B, C, D et E.

 

Recherche d’un fichier a.txt

A cherche à obtenir le fichier a.txt.

 

 

Figure 5 : Recherche d’un fichier dans Gnutella

 

 

A va envoyer un message Query (traits pleins rouges) aux premier nœud qu'il connaît (ici B), qui se charge

  1. de répondre s'il dispose de la ressource
  2. de propager la question

Les autres nœuds se comportent de façon identique tant que le nombre de sauts maximum n’est pas atteint.

P2P  Hybrides ou « super-peers »

 

La topologie précédente part du principe que tous les peers sont égaux. Hors cela n’est en pratique pas vrai. Les peers ont de fortes disparités en ce qui concerne leur bande passante, la capacité disque ou la puissance processeur. D’où l’idée de la création d’un modèle que l'on pourrait qualifier d'hybride entre le mode client/serveur et le P2P. Ces réseaux utilisent des serveurs mais ces serveurs sont suffisamment nombreux pour ne pas représenter un risque en cas de disparition de l’un d’eux.

 

On distingue deux types de réseaux hybrides :

 

  1. Les hybrides statiques : Certains pairs décident manuellement de faire tourner la partie serveur en plus de la partie cliente du réseau. ( Exemple du réseau E-Donkey )

 

  1. Les hybrides dynamiques : Dans certaines conditions, le logiciel client décide de transformer le nœud en serveur. ( Exemple de Kazaa et Skype)

 

    1. Les noeuds disposant d'une bonne bande passante sont organisés en P2P. Ce sont les super-peers

 

    1. les noeuds avec une faible bande passante sont reliés en mode client/serveur à un super-peer

 

    1. Les super-peers disposent d'un index des ressources de leur cluster.

 

 

Figure 6 : P2P Hybride ou Super Peer

 

P2P « Structuré » (DHT Distribued hashed table)

 

Chaque ressource reçoit une clé ( par exemple le nom de fichier ou sa valeur de hachage ).

Chaque pair va maintenir à jour une table de hachage  faisant la liaison entre la ressource et le pair. Cette table est distribuée sur l’ensemble des pairs qui conservent les valeurs correspondant à leur domaine. A l’insertion,  le couple (Clé, valeur) est placé sur le pair responsable de la clé et non sur le pair l’ayant inséré. Pour récupérer une clé, un nœud doit interroger le nœud responsable de la clé. Ce dernier lui fournit le nœud à interroger pour obtenir la donnée associée à la clé. Avec ce système, le nœud responsable est généralement trouvé en log(n) sauts dans un réseau comportant n participants.

 

Ces architectures permettent d’accéder à n’importe quelle donnée en log(n) sauts. Par contre, la procédure d’entrée dans le réseau pour un nouveau nœud est plus complexe en raison des opérations liées au partage de l’index.

 

Figure 7 : P2P Structuré

Exemple de Chord

 

Chord utilise ce type d’architecture. Chaque ressource K est associée au nœud N lui correspondant.

 

Exemple :

 

 

Figure 8 : Recherche dans CHORD

 

La donnée ayant la clé 54 est recherchée sur le nœud N8.

N8 consulte sa table de routage est voit que le nœud le plus proche de 54 est 42.

N8 transmet la requête à N42 qui recommence le même processus.

 

Avantages

  • Toute donnée est accessible en log(n) sauts.

Inconvénients

 

  • Sensibilité aux pannes. L’algorithme repose sur la notion de successeur et celui-ci peut être défaillant. Une solution est de gérer plusieurs successeurs.
  • La fonction de recherche minimise le nombre de sauts mais tous les sauts n’ont pas le même coût (par exemple traversée transatlantique)

 

P2P Sémantique

Routing Indices

Le fonctionnement est similaire aux P2P Structurées. Cependant les requêtes ne sont plus faites par rapport à un identifiant d’un document mais plutôt par rapport à son contenu. Le principe est de rajouter des informations aux tables de routage.

 

 

 

Figure 9 : Routing indices

 

Chemin

Nombre de documents

BDD

Langages

Réseaux

Théorie

B

100

20

30

0

10

C

1000

0

50

300

0

D

200

100

150

0

100

 

Tableau 1: Exemple de Routing Indices pour le noeud A

 

Le tableau 1 se lit de la façon suivante :
B peut accéder à 100 documents, dont 20 traitent de BDD, 30 de langages et 10 de théorie.
D accède à 200 documents : 100 concernent les BDD, 150 les langages, et 100 la théorie.

 

Algorithme de recherche

  • Résoudre localement la requête Q. S'il n'y a pas suffisamment de résultats :
    • Evaluer la proximité des successeurs
    • Tant qu'il n'y a pas assez de résultats
      • Prendre le successeur S le plus proche
      • Recherche (Q, S)
    • Retourner les réponses

Avantages

  • Le nombre de messages est diminué par rapport à l'algorithme de recherche de Gnutella
  • L'exploration est restreinte aux noeuds ayant la plus grande probabilité de succès

Inconvénients

  • Pas de garantie d'avoir tous les résultats
  • Pas d'informations sur le nombre de sauts nécessaires
  • Plutôt orienté recherche des K meilleurs résultats.
  • La structure d'indexation est assez simple, mais sa mise à jour génère beaucoup de messages
  • Fonctionne bien pour obtenir les meilleurs résultats, mais qui ne sont pas forcément tous les résultats
  • Nécessite la détection (ou la prévention) des cycles (A a pour fils B qui a pour fils C qui a pour fils A)

Semantic overlays networks (SON)

 

Les nœuds sont ici regroupées par thème. La recherche d’un document pourra être lancée dans le groupe correspondant. Il est possible paralléliser les SON afin d'obtenir des temps de réponse meilleurs). Un SON avec un seul label est un P2P non structuré.


 

Figure 10 :Exemple de SON

 

L'exemple présenté montre 8 noeuds classés par genre de musique.

Le lien entre A et B est : A, B, 'Rock'.
Les liens ayant le même thème forment un SON.
Ici, nous avons les SON suivants : Rock, avec les noeuds A, B et C ; Rap, avec B, E, et F; Jazz, avec E, F et G ; Techno, avec F, D et H ;

 

Avantages

Performances meilleures par rapport a un P2P non structuré

 

Inconvénients


 Ces réseaux reposent avant tout sur la classification des documents. Celle-ci est relativement complexe à mettre en oeuvre, et est surtout liée à un domaine précis.

Les SON favorisent la précision, mais pas la complétude.


 

Windows Vista et le P2P

Introduction

Actuellement, plusieurs facteurs freinent le développement des applications P2P. D’une façon générale, ces dernières sont beaucoup plus coûteuses qu’une application client/serveur car elles doivent gérer plusieurs problèmes tels que le NAT, les Firewalls et l’apprentissage d’un mode de programmation complexe. Ces barrières sont en partie abaissées avec les solutions introduites dans Windows Vista. Ainsi, IPV6 est installé par défaut. Pour gérer la compatibilité avec des réseaux IPV4, des protocoles d’encapsulation comme Teredo ou ISATAP ont été mis implémentés en natif. Enfin, le WCF ( Windows communication Fundation) avec son extension PeerChannel offre un moyen simple et standardisé de développer des applications P2P. 

 

Architecture

Figure 1: Windows Peer-to-Peer Networking architecture

 

Figure 11 :  Windows Vista & P2P

 

 

TCP/IP V6 : moyen de transport sur lequel s’appuie la technologie P2P de Windows

 

PRNP : protocole de résolution de nom ( comme pour le DNS ) . Un nom peut caractériser un pair, un service ou tout autre composant associé à une IP V6.

 

Graphing : gère les connexions et la communication entre les pairs.

 

Grouping : gère la sécurité. Il  permet de créer des groupes de pairs, d’envoyer des invitations et de rejoindre un groupe.

 

Network Addressing (NAT) et FireWalls.

La pénurie des adresses IP V4 a entraîné la mise en place des NAT (Network address translation). Chaque pair est alors identifié par une adresse privée.  Nat permet de router la réponse d’une requête à son auteur mais les autres pairs ne peuvent pas accéder avec son adresse privée. Un pair derrière un NAT peut alors travailler en mode client mais pas en mode serveur.

Les firewalls permettent le passage du trafic sortant mais bloquent le trafic entrant. Dans une application P2P, le nœud ne peut alors plus servir de serveur. Une solution pour permettre la connexion entre Pair A et B alors qu’ils sont tout deux derrière un Firewall est de router toutes les communications par un pair C qui est visible à la fois par Pair A et B.  JXTA et Gnutella utilisent des variations de cette approche.

IPV6

Les protocoles P2P de Windows Vista reposent sur IPV6. Ce choix permet de ne plus avoir à traiter le problème du NAT. Chaque service peut alors avoir sa propre adresse IP.

Il n’est pas nécessaire de convertir tout le réseau à IPV6, des protocoles d’encapsulation sont mis en place pour conserver la compatibilité.

 

L’architecture IP Windows vista est une architecture « dual stack ».  Les protocoles TCP V4 et TCP V6 sont différents ( de même que UDP )

Figure 12 : TCPIP V6 architecture dans Windows Vista

 

 

 

Figure 13 : Encapsulation IPV6 dans IPV4

 

Teredo (RFC 4380)

Teredo est installé par défaut sur Windows Vista. Par défaut, le firewall de vista laisse passer ses communications. Teredo devient toutefois inactif si le firewall de Vista est stoppé.

 

Cependant, dans le cas où d’autres firewall seraient actifs,  il est nécessaire d’ouvrir tous les ports UDP pour activer Teredo.

 

Il existe d’autres protocoles de tunneling IPV6 sur IPV4 : ISATAP ( rfc 4214, 6to4, 6over4)

 

Lors de la connexion au réseau, le pair, se connecte au serveur Térédo afin d’ouvrir un port. Par défaut le serveur Teredo est  teredo.ipv6.microsoft.com mais on peut aussi le configurer pour un autre serveur Teredo teredo.ipv6.wanadoo.fr.  Toutes les 20 secondes, des paquets de 50 octets sont envoyés au serveur afin de maintenir la connexion en vie. En procédant ainsi, le serveur Teredo pourra envoyer des données en réponse au client.

 

Lorsqu’un client A cherche à communiquer avec un client B,

1) il commence par lui adresser une bulle. Cette bulle est rejetée par le NAT du client B.

2) le client A informe alors le serveur Teredo de son intention de communiquer avec B

3) Le serveur Teredo informe le client B que A souhaite communiquer avec lui

4) Le client B envoit une bulle au client A afin d’ouvrir son port à une réponse du client A.

5) le serveur Teredo informe A que B est prêt à recevoir sa réponse

6) les deux pairs A et B peuvent commencer à échanger des données.

 

Figure 16: Initial communication between Teredo clients in different sites with restricted NATs

 

Figure 14 : Communication Teredo

 

PNRP

Afin de trouver les ressources et données sur le réseau P2P, le protocole PNRP est utilisé. Il est l’équivalent d’un service DNS mais avec des caractéristiques fortement différentes.

 

  • Pas de serveur central.  Mis à part la connaissance d’un premier voisin (serveur toujours connecté au nuage IPV6) afin d’entrer dans le nuage, il n’y a aucun serveur conservant une liste de noms.
  • La publication de nouveaux noms peut se faire simplement à partir du client (contrairement au dns qui nécessite l’intervention sur le serveur  DNS)
  • Mise à jour rapide. Le changement d’une adresse est très rapide ( contrairement au DNS qui peut prendre plusieurs jours)
  • Un nom caractérise un service et pas seulement un pair
  • Un nom est soit protégé par une clé privé, soit public.

 

PNRP Clouds

PNRP utilise des « nuages ». Un nuage correspond à un groupe de pair. Ces nuages correspondent aux « scopes » IPV6. C'est-à-dire soit Local (réseau local) soit Global (Internet).

 

Les Noms des Pairs et le PNRP ID

 

Un nom de pair peut caractériser une machine, un utilisateur, un groupe, un service ou tout autre objet qui a une adresse IPV6. Les noms peuvent être sécurisés ou non. Les noms non sécurisés peuvent être publiés par tous et donc peuvent présenter une faille de sécurité. Il est recommandé de ne les utiliser que dans des réseaux privés. Les noms sécurisés sont protégés par un certificat et une signature.

 

Les ID PNRP ont une longueur de 256 bits.

 

Les 128 premiers bits sont le P2P ID. Pour un nom non sécurisé, le P2P ID est égal à 0. Pour un nom sécurisé, le P2P ID est composé de la concaténation entre le hash de la clé publique et le nom courant de la ressource.

 

Les 128 derniers bits vont identifier le nœud dans le cercle PNRP.

 

Figure 1. P2P and PNRP IDs

 

Figure 15 : Identification PNRP

 

 

 

PNRP Résolution

 

Dans la première version de PNRP, la résolution était récursive, chaque nœud passait la  demande de résolution à son voisin.

 

Dans Vista, elle est maintenant itérative, le nœud est responsable de la résolution de nom et va interroger successivement les nœuds renvoyés par ses voisins pour trouver la ressource.

 

Figure 3  PNRP endpoint determination example

Figure 16 : PNRP Résolution

 

 

Peer A ( Id 200) cherche à trouver le PNRP ID 800

 

1) Peer A connaît C ( 500 ) et B (450 ). Puisque C est plus proche de 800 que B, c’est lui qui est interrogé.

2) Peer C répond qu’il ne connaît pas 800 et n’a aucune entrée plus proche de 800.

3) Peer A va alors interroger B qui est le second plus proche de 800

4) Peer B connaît 800 et renvoie l’adresse IPV6 de E

5) Peer A envoie une requête PNRP à E.

6) Peer 2 renvoie une réponse positive à A

PNRP Cache

L’architecture interne de PNRP est très proche des P2P structurés ( DHT ). Il ne maintient pas de tables distribuées mais gère un cache. Son organisation est circulaire comme celle de Chord.

Les voisins proches sont en plus grand nombre dans la table que les voisins lointains.

 

 

 

 

Figure 17 : PNRP Cache

 

Graphing

 

Le composant Graphing gère la connexion et la communication entre les nœuds. Il est responsable de l’ajout / suppression / modification de nœuds dans le graphe.

 

Lors de l’ajout d’un nœud dans le graphe, le nœud choisit un « node id » qui doit être unique dans le graphe. La valeur la plus petite du nœud du graphe sert de signature au graphe. Cette signature sert à détecter les partitions dans le graphe.

 

Optimisation des connexions entre nœuds

 

Un pair peut recevoir la même information de plusieurs nœuds. Dans l’exemple ci-dessous, 800 envoie une requête à ses voisins : 450, 500 et 350.

Le nœud 350 va recevoir la même information de la part de 800, 500, 200 et 450. L’information  autre que celle de 800 n’est pas prise en compte. Cependant un index est gardé en mémoire pour vérifier la pertinence de la connexion entre deux nœuds. Au bout d’un moment si un nœud ne fournit pas d’information « fraîche » , la connexion est rompue et le nœud se choisit un nouveau voisin.

 

Figure 18 : Communication entre les nœuds

 

Connexion au graphe

Lorsqu’un pair A cherche à se connecter au graphe, il a besoin de connaître au moins un nœud connecté (pair B). Il demande une connexion à pair B. Si pair B a dépassé le nombre de voisins auquel il peut être connecté dans le graphe, il va renvoyer une réponse négative avec une liste de tous ses voisins. Le pair A va alors de nouveau renouveler sa demande de connexion avec l’un des voisins de B. Une fois connecté au graphe, le pair A peut répéter l’opération pour trouver d’autres voisins.

 

Déconnexion du graphe

Lorsqu’un nœud se déconnecte du graphe, il envoie un message de déconnexion à ses voisins avec une liste de voisins. Ses voisins vont alors essayer de se connecter à un nouveau voisin de la liste.

 

Détection et réparation d’une partition dans le graphe.

Lors de la déconnexion de nœuds, il peut se produire des partitions dans le graphe. Chaque graphe possède une signature ( l’id du nœud le plus bas ) et une liste de contacts ( le nombre de contacts dépend de la taille du graphe ). Les informations de contact et de signature sont diffusées à tous les nœuds du réseau et rafraîchies périodiquement. Si l’information n’est pas rafraîchie alors une partition s’est produite et le nœud essaye de contacter le contact afin de se reconnecter. Un nœud peut appartenir à plusieurs graphes.

 

Exemple :

Le graphe commence avec le nœud A ( Id 2 , contact A)

B se connecte au graphe par l’intermédiaire de A, il récupère l’information signature et contact de A.

B a un ID 1 qui est inférieur à 2. La signature du graphe devrait donc être 1 au lieu de 2.  B diffuse donc l’information de nouvelle signature du Graphe.

A remplace l’information de signature du graphe par celle venant de  B.

A voit que le contact A est associé au graphe 2 , il met donc à jour l’information de contact pour le graphe 1 et renvoie l’information à B.

 

Figure 7: Example Graph X with six nodes

 

Figure 19 : Exemple d’un graphe

 

D’autres nœuds rejoignent le graphe ( C,D,E,F ) pour obtenir une topologie telle que dans la figure ci-dessus.

Le graphe a alors une signature de 1 ( noeud B )  et deux contacts : A et D. La signature est rafraîchie toutes les 5 minutes par le nœud B ( qui a l’id 1 ).

 

Dans le cas où une coupure survient entre A et E.

 

Les nœuds D, E, F ne reçoivent pas le rafraîchissement de la signature venant de B. Au bout de l’expiration du délais de la signature, le nœud D ( Id 7)  envoie une information de nouvelle signature du graphe à ses voisins E et F.

 

A la réception de ce message, E et F remplacent leur information de signature de graphe. D remplace son information de contact avec une signature de 7 et renvoie cette information aux autres nœuds.

 

Les nœuds D,E,F ont alors deux informations de contacts. Un contact A avec une signature de 1 et un contact D avec une signature de 7.  Afin de résoudre cette information contradictoire, chacun va essayer de se connecter au contact A après un délais aléatoire.

 

Le nœud D arrive à se reconnecter avec A et ils échangent alors leurs informations de contact et de signature. Le nœud A envoie une signature de 1 alors D a une signature de 7. D remplace alors sa signature de graphe et renvoie l’information à ses voisins E et F. 

D met à jour son information de contact pour l’associer à la signature 1  et diffuse l’information à ses voisins A, E, F.

 

A la fin du processus, le graphe a convergé de nouveau, la connexion a pu être rétablie.

 

PeerChannel et WCF ( Windows communication Fundation )

 

Actuellement, la communication entre deux objets distants peut se faire de manières :  Web services,  .NET Remoting ( communication binaire ) ,  SMTP, MSMQ ,  …

 

Chaque méthode nécessite une programmation différente et est difficilement interopérable avec l’autre.

 

WCF est la solution de microsoft  pour avoir un langage commun quelque soit le mode de communication entre les objets.

 

 

Figure 20 :   Windows communicaton fundation

 

 

 Chaque service présente un contrat. C’est ce contrat qui est codé dans l’application. La programmation du code est indépendante du « binding » c'est-à-dire de la façon dont les objets vont communiquer.

 

Il devient donc aussi facile de développer des applications P2P en utilisant le binding NetPeerTcpBinding. 

 

Le terme PeerChannel est couramment utilisé pour évoquer les possibilité de développement P2P avec WCF.

 

Exemple de code à rajouter dans le fichier de configuration :

 

<client>

   <!-- chat instance participating in the mesh -->

   <endpoint name="SecureChatEndpoint"

            address="net.p2p://SecureChatMesh/servicemodelsamples/chat"

             binding="netPeerTcpBinding"

             bindingConfiguration="SecureChatBinding"

             contract="Microsoft.ServiceModel.Samples.IChat">

   </endpoint>

 </client>

 

et dans le code :

 

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples", CallbackContract = typeof(IChat))]

    public interface IChat

    {

        [OperationContract(IsOneWay = true)]

        void Join(string member);

 

        [OperationContract(IsOneWay = true)]

        void Chat(string member, string msg);

 

        [OperationContract(IsOneWay = true)]

        void Leave(string member);

    }

 

Applications utilisant la technologie P2P Vista

 

Radius

 

Application de reporting permettant aux utilisateurs de créer, et partager leurs rapports avec les autres utilisateurs

 

http://www.90degreesoftware.com/

 

 

CarbonCloud

 

Solution permettant le partage  de fichiers,  contacts, …

http://www.thecarbonproject.com/social.php


 

Conclusion

 

Apparus avec Napster, les applications P2P sont très adaptées pour plusieurs types d’application. Cependant, elles restent actuellement très complexes à développer du fait des contraintes techniques dues au NAT  et firewall. 

 

Avec l’arrivée de Windows Vista et de .NET Framework 3.0, les obstacles au développement d’applications P2P vont être abaissés.  La mise à disposition en natif de technologies telles que  PNRP, IPV6 et un développement des applications plus facile grâce au peerchannel de WCF va très probablement donner naissance à une nouvelle ère de développement d’applications P2P.  Il est probable que nous aboutissions à des applications collaboratives que nous pouvons aujourd’hui difficilement imaginer.

Projets P2P

 

 

 

 

 

 

 

  • JXTA : fournit un ensemble de protocole et d’api pour le developpement d’applications P2P http://www.jxta.org/

Bibliographie

 

 

  1. MAC DONALD M. Peer to Peer with VB.NET. Apress, 2003

 

  1. LE FESSANT F. Peer to Peer comprendre et utiliser. Eyrolles, Paris, 2006.

 

  1. TAYLOR I. From P2P to web services and grids. Springer, Londres, 2005.

 

  1. McMURTRY C., MERCURI M., WATLING N. Microsoft® Windows® Communication Foundation Hands-on. Sams, 2006.

 

  1. LEUF B. Peer to Peer: Collaboration and Sharing over the Internet. Addison Wesley, 2002.

 

  1. SUBRAMANIAN R., GOODMAN B. Peer to peer computing: the evolution of a disruptive technology. Idea Group Publishing, Hershey, USA, 2005.

 

  1. Site Microsoft dédié au P2P. http://www.microsoft.com/technet/network/p2p/default.mspx

 

  1. Site Microsoft dédié à IPV6. http://www.microsoft.com/technet/network/ipv6/default.mspx