S.Feres - Les réseaux peer to peer - UFRIMA - Octobre 2003 1 Les Réseaux « peer to peer »

S.Feres - Les réseaux peer to peer - UFRIMA - Octobre 2003

1

Les Réseaux « peer to peer »

S.Feres - Les réseaux peer to peer - UFRIMA - Octobre 2003 2

Plan

1. Le peer to peer1. Définition2. Historique3. Applications4. Les différentes architectures5. Comparatif (avantages / inconvénients)

2. Le protocole Gnutella3. Le projet JXTA


Le peer to peer : Définition

• Peer to peer en français : « d’égal à égal » ou « pair à pair »

• Système d'échange direct de ressources entre machines connectées en réseau

• Se distingue fondamentalement de l’architecture client / serveur


Le peer to peer : HistoriqueHistorique :

– Années 60 : à l’origine Internet était axé sur l’ échange d’informations entre universités (Arpanet)

– 1999 : Napster (S.Fanning), architecture centralisée qui compte plus de 25.000.000 d’usagers en 2000

– 2000 : Gnutella (AOL – Nullsoft), architecture décentralisée

– 2001 : Kazaa (Zennstrom & Fiis) , projet JXTA (Sun), architecture centralisée-décentralisée


• Calcul distribué• Ex : projet SETI

• Échange de fichiers• Ex : Napster, Gnutella, Kazaa, …

• Stockage distribué, plate-forme de développement et groupes de collaboration

• Ex : JXTA

Le peer to peer : Applications


Le peer to peer : Architectures

• Architecture centralisée :– Mise en relation à partir du serveur– Puis liaison directe entre les clients

• Architecture client / serveur :– Ce n’est PAS un réseau peer to peer– Ici tout passe par le serveur– Aucune liaison directe entre les clients



• Architecture décentralisée :

– Égalité entre tous les utilisateurs– Liaisons établies de proche en proche– Requêtes transférées et relayées– Fichiers transférés directement du

demandeur au donneur– Réseau en perpétuelle mutation



• Architecture centralisée-décentralisée (utilisation d’ « ultra-peers ») :

– Pratiquement le même schéma que l’architecture décentralisée

– Permet de palier au problème de la bande passante


Le peer to peer : Comparatif

• P2P centralisé– Avantage :

• Efficacité des recherches, facilité d'utilisation

– Inconvénients : • Complètement tributaire du serveur central• Aucun anonymat n'est garanti• Possibilité pour le serveur central de créer des

fichiers clients et des profils d’utilisateurs pour les revendre à des compagnies spécialisées



• P2P décentralisé– Avantages :

• Grande souplesse, grande robustesse• Anonymat (relatif) assuré car il n'y a pas de

serveur qui stocke des données sur les utilisateurs

– Inconvénients : • Problèmes au niveau de la bande passante• Anonymat => risques de piratage et d’échange

de données illégales



• P2P centralisé-décentralisé– Avantages :

• Les mêmes qu’en décentralisé• Plus de bande passante

– Inconvénients : • Choix difficile des ultra-peers• Compliqué à mettre en place


Plan

1. Le peer to peer2. Le protocole Gnutella

1. Introduction2. Description3. Inconvénients4. Nouvelle version

3. Le projet JXTA


Le protocole Gnutella : Introduction• Développé en 2000 par NullSoft (J.Frankel &

T.Pepper) qui fut ensuite racheté par AOL-Time-Warner

• Dédié avant tout au partage de fichiers• Chaque utilisateur joue à la fois le rôle de

client et de serveur : on les appelle les servants


Le protocole Gnutella : Description

• Ce protocole fonctionne au moyen de 5 descripteurs principaux :– Ping– Pong– Query– QueryHit– Push

• Ces descripteurs permettent la transmission :– Des infos entre les servants (nœuds) du réseau– Des règles qui régissent l'échange de ces descripteurs


Le protocole Gnutella : Description• EN-TETE des descripteurs :

– Descriptor ID : identifie le descripteur de façon unique– Payload Descriptor :

0x00 : Ping 0x40 : Query 0x81 : Push0x01 : Pong 0x80 : QueryHit

– TTL : « time to live » indique le nombre de sauts que peut encore effectuer le descripteur entre servants Gnutella avant sa destruction

– Hops : nombre de sauts déjà accomplis– Payload Length : indique la longueur du descripteur suivant

immédiatement l'en-tête

DescriptorID

Payload Descriptor

TTL Hops

Payload length

0 16 17 18 19 22



• Descripteur PING• N'a pas de Payload associé• Ne contient qu’ un en-tête dans lequel

Payload Lenght vaut 0x00000000 et Payload Descriptor vaut 0x00

• Permet de sonder le réseau à la recherche d'autres servants

• Chacun des servants qui reçoit un Ping répond avec un Pong



• Descripteur PONG

• Port : numéro de port sur lequel le servent atteint peut accepter les connexions incidentes.

• IP Adress : adresse IP du servent atteint.• Nb of files shared, Nb of kB shared : nombre de fichiers

et nombre d'octets de données partagés par le servant défini par le port et l'adresse IP précédents.

N.B : à un Ping reçu, plusieurs Pongs peuvent être renvoyés. Cela permet à un servant de renvoyer des infos le concernant personnellement, mais aussi des infos qu'il gardait en mémoire cache sur d'autres servants.

Port IP adress Nb of files shared

Nb of kB shared

0 2 6 10 13


Le protocole Gnutella : Description• Descripteur QUERY

• Minimum speed : vitesse minimale (en ko/s) des servants qui doivent répondre à ce message. Les servants plus lents que ce seuil ne sont pas censés répondre

• Search Criteria :

– Cette chaîne contient des critères de recherche, tels que des noms de fichier, ou des types de fichiers (MP3, jpeg,...) et se termine par 0x00

– Sa longueur n'est limitée que par le Payload length de l'en-tête

Minimum speed Search Criteria

0 2 …



• Descripteur QueryHit

– Nb of hits : Nb de "coups au but" dans le Result Set

– Port : Le numéro de port sur lequel le servant atteint peut accepter les connexions incidentes

– IP Adress : Adresse IP du servant atteint– Speed : Vitesse du servant atteint

Nb of hits Port IP Adress Speed Result Set Servant ID

0 1 3 7 11 n n+16


Le protocole Gnutella : Description• Descripteur QueryHit

• Result Set :

– File Index : nombre attribué par le servant répondant, destiné à identifier de façon unique le fichier correspondant à la requête.

– File Size : Taille en ko du fichier référencé par File Index.

– File Name : Nom du fichier référencé par File Index, se termine nécéssairement par 0x0000. Sa taille est limitée par le champ Payload Lenght de l'en-tête.


0 1 3 7 11 n n+16

File Index File Size File Name

0 4 8 …



• Descripteur QueryHit

•Servant ID : Chaîne de 16 octets qui identifie le servant répondant à la requête.

– Un QueryHit n'est envoyé que si le servant possède des fichiers correspondants aux critères de recherche d'un Query

– Le champ Descritpor ID dans l'en-tête du QueryHit doit contenir la même valeur que le champ Descritpor ID de l'en-tête du Query


0 1 3 7 11 n n+16



• Descripteur PUSH

– Servant ID : Chaîne de 16 octets qui identifie le servant à qui l'on demande de "pousser" le fichier référencé par File Index.

– File Index : Cet index détermine le fichier qui doit être "poussé" à partir du servent cible.

– IP Adress : Adresse IP du servant vers lequel le fichier référencé par File Index doit être "poussé".

– Port : Port vers lequel le fichier référencé par File Index doit être "poussé".

Servant ID File Index

IP adress

Port

0 16 20 24 25


Le protocole Gnutella : Description• Descripteur PUSH

– Utilité :• Palier au problème des FireWalls• Lorsqu’on est derrière un firewall, au lieu

d’initier soit même la connexion, le servant qui possède le fichier l’initialise en « poussant » le fichier



• Routage des descripteurs – Les Pongs (resp. QueryHit, Push) empruntent le

même chemin que les Pings (resp. Query ) auxquels ils répondent

– Un servant recevant un Ping (ou Query) le transmettra à tous ses voisins immédiats, sauf celui d'où provient le descripteur

– Chaque servant, à la réception d'un descripteur, décrémente son TTL et incrémente son Hops

– TTL = 0 => le descripteur n'est plus transmis– Non transmission des descripteurs ayant le même

payload et DescriptorID qu’un autre reçu précédemment



•A se connecte

•A envoie un Ping à B et C

•B et C répondent avec un Pong

•Un Query est lancé par A

•Le Query est relayé jusqu'à un servent possédant les fichiers demandés

•Celui-ci renvoie un QueryHit contenant la liste des fichiers vérifiant les critères de recherche

•Le téléchargement se fait via HTTP


Le protocole Gnutella : Inconvénients

– Réseau inondé de Pings :• si la connectivité moyenne d'un servant est de n, on obtient

n^TTL Pings sur le réseau !

– Beaucoup d’utilisateurs ont une connexion lente (modem 56K)

– Problème du descripteur Push :• un servant ne sait pas s'il se trouve derrière un Firewall ou

encore que le servant qu'il essaye de joindre se trouve derrière un Firewall

– Immense gâchis de bande passante


Le protocole Gnutella : Nouvelle version

• Concept des ultrapeers– Hierarchie des

nœuds– Choix des ultrapeers

basé sur les capacités de calcul et de bande passante



• L’ultrapeer envoie périodiquement des "indexing queries" à ses fils qui répondent en envoyant chacun leur liste de fichiers partagés

• L’ultrapeer ne fait suivre les Query qu’aux clients qui ont une entrée correspondante.

• Concept compatible avec les clients anciens qui sont vus comme des ultrapeers sans fils.



• Choix des ultrapeers :• L’ordinateur ne doit pas être situé

derrière un firewall et doit avoir un système d’exploitation relativement récent.

• Doit avoir une bande passante et un processeur de bonne qualité.

• Doit être sur le réseau depuis assez longtemps.


Le protocole Gnutella : Problème

• Beaucoup de « pillards »

• Répartition des fichiers inégales


Le protocole Gnutella : Solution

• Réplication des données– Réplication après téléchargement– Réplication « sur le chemin »– Réplication au hasard

• Evite une concentration des fichiers• Difficile à mettre en place


Quelques clients Gnutella :

• LimeWire• Shareazaa• BearShare• Gnucleus• Morpheus• Ares


Exemple de client Gnutella : FreeWire


Plan

1. Le peer to peer2. Le protocole Gnutella3. Le projet JXTA

1. Introduction2. L’architecture3. Les concepts4. Les protocoles5. Conclusion


JXTA : Introduction

• Pourquoi un tel projet ?– De plus en plus d’internautes– Un engouement pour le p2p– Les mêmes problèmes rencontrés par les

développeurs

• Les objectifs– Interopérabilité : facilité de localisation et de

communication quels que soient les systèmes– Indépendance envers les plates-formes :

langages (C, Java…), systèmes (Windows, Unix…) et réseau (TCP/IP, Bluetooth…)

– Ubiquité : tout type de support (PDA, routeurs, ordinateurs…)


JXTA : Architecture• La structure possède 3 couches :

– Le noyau : JXTA Core– La couche des services : JXTA Services– La couche des applications : JXTA Applications


JXTA : Architecture• JXTA Core

– Encapsule le minimum pour avoir un réseau p2p– Les applications communiquent à travers ce noyau

• JXTA Services– Propose différents services optionnels :

• Recherche, partage de fichier, authentification …

• JXTA Applications– Couche la plus haute– Instant messaging, e-mail, etc…


JXTA : Concepts

• Pipes– Tubes de communication unidirectionnels pour

envoyer et recevoir des messages– Ils supportent tout type d’objets– Deux types de connexions :

• Connexion point-à-point• Connexion par propagation

• Annonces– Messages XML qui nomment, décriventt et publient

l’existence d’une ressource– Durée de vie limitée


JXTA : Concepts

• Peer pipes


JXTA : Concepts

• Peer– Entité qui peut communiquer à travers les protocoles

JXTA.– Fournissent une interface pour des connections point-

à-point– Recherchent des autres pairs pour former des

relations passagères ou durables appelées « peer groups »

• Peer Groups– Collection de peers coopérant et fournissant un

ensemble de services communs– Un peer peut appartenir à plusieurs groupes– Le groupe par défaut est le « Net Peer Group »


JXTA : Protocoles

• JXTA définit une série de messages XML pour la communication entre peers

• Utilisés pour découvrir d’autres peers, annoncer et trouver des ressources pour la communication et le routage

• Ils sont basés sur le principe question/réponse


JXTA : Protocoles

• Des protocoles aux nombres de six :– Peer Discovery Protocol : trouver les annonces sur

d’autres peers et rechercher des ressources (Peers, Peers group, pipe, services)

– Peer Resolver Protocol : envoyer et recevoir des requêtes génériques ciblées

– Peer Information Protocol : prendre connaissance du statut d’un autre peer

– Peer MemberShip Protocol : obtenir les autorisations pour accéder à un groupe

– Peer Binding Protocol : établir un Pipe entre 2 ou plusieurs peers

– Peer Endpoint Protocol : demander à un routeur les accès disponibles pour envoyer un message à un peer cible


JXTA : Conclusion

• Une technologie encore jeune• De nombreuses applications en cours de

développement• Un futur standard ?


Références

– http://www.zdnet.fr– http://solutions.journaldunet.com– http://www.openp2p.com– http://www-lor.int-evry.fr– The O’Reilly Peer-to-Peer and Web services

Conference, Washington DC – Sept.18-21, 2001 :

• http://conferences.oreilly.com/p2p

– http://www.jxta.org– http://www.gnutella.org

Documents

S.Feres - Les réseaux peer to peer - UFRIMA - Octobre 2003 1 Les Réseaux « peer to peer »