Systèmes et applications répartis

SMB111, 6 ECTS

Chapitre 6 – Séance 9
Le pair-à-pair
Le plus grand soin a été apporté à la réalisation de ce support pédagogique afin de vous fournir une information
complète et fiable. Cependant, le Cnam Champagne-Ardenne n'assume de responsabilités, ni pour son utilisation,
ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter de cette
utilisation.

Les exemples ou programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques. Ils
ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle.

Le Cnam ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature que
ce soit pouvant résulter de l'utilisation de ces exemples ou programmes.

Tous les noms de produits ou autres marques cités dans ce support sont des marques déposées par leurs
propriétaires respectifs.

Ce support pédagogique a été rédigé par Cyril Rabat, enseignant vacataire au Cnam Champagne-Ardenne.

Copyright  2012-2013 - Cnam Champagne-Ardenne.

Tous droits réservés.

L'utilisation du support pédagogique est réservée aux formations du Cnam Champagne-Ardenne. Tout autre usage
suppose l'autorisation préalable écrite du Cnam Champagne-Ardenne.

Toute utilisation, diffusion ou reproduction du support, même partielle, par quelque procédé que ce soit, est
interdite sans autorisation préalable écrite du Cnam Champagne-Ardenne. Une copie par xérographie,
photographie, film, support magnétique ou autre, constitue une contrefaçon passible des peines prévues par la loi,
du 11 mars 1957 et du 3 juillet 1995, sur la protection des droits d'auteur.

Edition du 7 décembre 2012

 Les systèmes pair-à-pair sont souvent associés à des applications de partage de fichiers, le plus
souvent illégales. Bien que cette utilisation les a rendus très populaires auprès du grand public, ils ont
permis d’apporter de multiples solutions très efficaces dans des domaines aussi variés que le stockage
de données, le calcul distribué, la téléphonie, la télévision, etc.

Dans ce cours, nous allons aborder le concept des systèmes pair-à-pair en définissant les
principaux termes associés et en présentant différentes applications possibles. Nous étudierons plus en
détail le système Skype qui permet de faire de la téléphonie pair-à-pair.

N.B. : de nombreux systèmes de partage de fichiers sont cités dans ce cours (tels que Gnutella,
Napster, KaZaA, BitTorrent). Leur fonctionnement n’est pas détaillé ici mais fait l’objet du prochain
cours.

1. Qu’est-ce que le pair-à-pair ?

1.1. Définitions

Le terme provient de l’anglais peer-to-peer (souvent abrégé en P2P), qui est aussi traduit par
« égal à égal ». Indépendamment du type d’application, il s’agit surtout d’un modèle de
communication. Les différentes entités du système communiquent directement entre elles. De plus,
elles possèdent aussi bien les fonctionnalités de client que de serveur, prenant tantôt les fonctions de
l’un, tantôt les fonctions de l’autre, voire simultanément des deux. L’un des principaux avantages est
qu’une seule application est nécessaire pour toutes les machines.

Il existe plusieurs éléments associés au pair-à-pair : le réseau, le protocole et l’application. Un

autre élément est le réseau overlay. Un pair est une entité d’un système pair-à-pair. C’est un hôte
quelconque sur lequel une application pair-à-pair est exécutée. Il est connecté au réseau pair-à-pair,
c’est-à-dire qu’il peut recevoir des messages des autres pairs ou en envoyer. Les pairs peuvent être
hétérogènes (PC, téléphones, PDA…) et dynamiques (connexions et déconnexions fréquentes).

Un réseau pair-à-pair est constitué de l’ensemble des pairs. Il correspond donc à la partie
physique du système pair-à-pair. Il est caractérisé par l’utilisation d’un unique protocole.

Un client pair-à-pair correspond à l’application exécutée sur chaque pair et qui permet de le
connecter au réseau pair-à-pair. Généralement, tous les pairs possèdent la même fonction, ce qui
signifie qu’une seule application est nécessaire. Cependant dans certains systèmes, des entités
possèdent des rôles différents comme les serveurs dans Napster dont le but est de mettre en relation
l’ensemble des pairs du système. Les clients communiquent entre eux à l’aide d’un même protocole.

Le protocole pair-à-pair permet de définir le format des messages envoyés entre les
différents pairs du système et les différents échanges possibles. Si la plupart des protocoles pair-à-pair
sont ouverts, certains sont cependant propriétaires permettant une certaine « sécurité », mais surtout
obligeant l’utilisation du client officiel (c’est le cas avec KaZaa et Skype). Les protocoles sont
généralement encapsulés dans des protocoles de transport (TCP ou UDP) ou dans le protocole HTTP,
permettant ainsi le passage des pare-feu.

Un système pair-à-pair correspond à un réseau, un protocole et un client. Dans la suite, nous

utiliserons plus souvent ce terme. Il faut noter cependant que dans de nombreux systèmes pair-à-pair,
le protocole est ouvert laissant la liberté aux développeurs de proposer des clients avec des
fonctionnalités spécifiques mais compatibles avec les autres. C’est le cas par exemple avec BitTorrent
où un grand nombre de clients différents ont été développés (Azureus, BitTorrent, LimeWire, Torrent,
Vuze...). Ce qui veut dire que dans ce type de système, des clients différents peuvent très bien
coexister.

Le réseau virtuel (en anglais overlay network) correspond à l’ensemble des pairs et aux
connexions entre ces pairs. La particularité des systèmes pair-à-pair est le nombre très important de
pairs connectés (plusieurs centaines de milliers dans les systèmes de partage de fichiers comme

Le pair-à-pair 1 / 12
Gnutella et des millions avec Skype). Il est donc impossible pour chacun de connaître l’ensemble des
autres pairs à cause de la mémoire qui serait nécessaire, du coût engendré par cette mise-à-jour
constante et du nombre de connexions TCP limité par le système. Généralement, des liens sont établis
avec un nombre réduit de pairs. Ceux-ci sont choisis soit de manière aléatoire (comme BitTorrent),
soit suivant les intérêts des pairs (kadmelia). Les liens peuvent être soit établis « physiquement »
comme une connexion TCP, soit ils peuvent correspondre à une connaissance (l’adresse IP du pair ou
de son identité). L’ensemble des pairs ainsi que les liens entre les pairs forment le réseau virtuel. Au
sein de ce réseau virtuel, construit au-dessus du réseau IP, des mécanismes de routage, de nommage
sont nécessaires.

(a) (b)
Figure 1 : représentation d'un réseau overlay (b) à partir d'un ensemble de pairs (a)

La Figure 1 montre un exemple de réseau virtuel. Sur la Figure 1 (a), un ensemble de pairs est
interconnecté dans le système via un client quelconque. La Figure 1 (b) représente le réseau virtuel
avec les connexions entre les pairs. Dans cet exemple, il y a peu de pairs et peu de connexions. Dans
la réalité, chaque pair peut avoir beaucoup plus de connexions avec les autres.

1.2. Problématiques

Comme nous l’avons dit précédemment, le nombre de pairs dans un système peut être très
important. L’une des premières problématiques est de permettre la connexion de tous les pairs
possibles, sans que les performances du système ne se dégradent. Dans la première version de
Gnutella, le nombre de messages nécessaires à la maintenance de la topologie était trop élevé, ce qui
gâchait la bande passante inutilement.

Une problématique concerne la volatilité des ressources. En effet, les clients sont installés sur
les machines des utilisateurs et ceux-ci peuvent les éteindre, les redémarrer à volonté. Le système
doit donc prévoir ces connexions et déconnexions fréquentes.

Si l’on cumule les deux problématiques précédentes, les systèmes pair-à-pair doivent aussi
gérer l’apparition et la disparition simultanée d’un grand nombre de pairs, phénomène appelé le
churning. En effet, si le réseau overlay permet de limiter la connaissance de chaque pair, celle-ci doit
être suffisante pour empêcher la perte de connexion d’une partie des pairs.

L’hétérogénéité est aussi un problème très important. Les clients sont exécutés sur des
machines ayant des caractéristiques différentes (systèmes d’exploitation, capacités de calcul, de
mémoire ou de stockage) et reliées via Internet (les débits sont très différents). De plus, cette
hétérogénéité n’est pas statique : le débit fluctue dans le temps, de même que les ressources
disponibles sur les machines.

Enfin, les utilisateurs se trouvent généralement dans des réseaux privés ou derrière des pare-
feu. Ceci limite les possibilités d’établissement de connexions et il faut trouver des parades pour que
ces pairs puissent se connecter au système et recevoir des messages.

SMB111 2 / 12
 1.3. Applications du pair-à-pair

1.3.1. Le partage de fichiers

L’objectif de ce type d’applications est de permettre le partage de fichiers. Chaque pair possède
ses propres fichiers et a la possibilité de télécharger ceux des autres pairs. Un fichier est généralement
caractérisé par son type (son extension, par exemple) et par des mots-clefs (la plupart du temps
contenus dans son nom de fichier). Un utilisateur peut lancer une recherche sur un fichier particulier
qui, si elle est fructueuse, lui donne une liste de pairs possédant ce fichier ou une liste de fichiers
contenant les mots-clefs recherchés. L’utilisateur peut alors sélectionner le fichier qui sera ensuite
téléchargé.

Suivant les protocoles, il est possible de télécharger intégralement le fichier depuis une source
unique ou alors de le télécharger par petits blocs. Ceci apporte plusieurs avantages. Si la connexion
est perdue avant la fin du téléchargement, celui-ci peut reprendre à partir du dernier bloc reçu. L’autre
avantage est de pouvoir télécharger différents blocs depuis différentes sources, améliorant ainsi la
rapidité du téléchargement.

Les systèmes pair-à-pair de partage de fichiers font l’objet du prochain cours.

1.3.2. Le stockage de données

La quantité de données numériques à stocker est toujours de plus en plus importante. Or, les
capacités de stockage (disques durs, CD/DVD, clefs USB…) ne sont pas fiables à 100%. Leur panne ou
leur altération implique la perte des données stockées. Une solution pair-à-pair est d’exploiter les
capacités de stockage inutilisées des pairs du système pour stocker les fichiers. Ce type d’application
doit répondre à plusieurs problématiques :
1) Assurer la persistance des données ;
2) Donner la possibilité de récupérer les données à tout moment ;
3) Assurer la confidentialité des données ;
4) Permettre la mise-à-jour (assurer la cohérence des données)…

Lorsqu’un utilisateur stocke ses fichiers via un système quelconque (systèmes centralisés avec
des outils comme DropBox ou Google Drive, applications de stockage type cloud), il doit être assuré
qu’ils ne disparaîtront pas. Le système pair-à-pair doit donc mettre en œuvre des moyens pour cela.

Pour récupérer les données à tout moment, il faut qu’au moins un pair qui les possède soit en
ligne. Suivant la stabilité des pairs du réseau, il faut donc recopier les données sur suffisamment de
pairs, sans pour autant faire trop de réplicas pour ne pas gâcher l’espace de stockage. Un système de
notation peut être mis en place afin de privilégier l’utilisation de nœuds plus statiques : les données
sont réparties sur ces pairs, puis la réplication est faite sur d’autres moins fiables.

Les données sont stockées sur un pair quelconque du réseau, c’est-à-dire dans son système de
fichiers. Il faut donc s’assurer que le propriétaire de la machine ne soit pas dans la possibilité
d’accéder au contenu du fichier ou d’un des blocs. Dans le cas de FreeNet, toutes les données sont
ainsi cryptées, empêchant l’utilisateur de connaître précisément ce qu’il possède.

La mise-à-jour est, elle-aussi, problématique. En effet, si un fichier est mis-à-jour par son
propriétaire, il faut être en mesure de répercuter cette mise-à-jour et s’assurer qu’un pair déconnecté
qui possédait une partie du fichier, ne pose aucun problème de cohérence lorsqu’il se reconnecte à
nouveau.

1.3.3. Le calcul pair-à-pair

Au même titre que pour le stockage, l’objectif du calcul pair-à-pair est d’exploiter les ressources
inutilisées des pairs. Ici, c’est la puissance de calcul qui est récupérée pour réaliser des calculs
globaux. Les problématiques sont cependant très différentes. Alors que dans le cas du stockage, les

Le pair-à-pair 3 / 12
données stockées sont « inactives », le calcul implique qu’un code inconnu doit être exécuté sur les
machines des participants. Ces systèmes doivent donc répondre aux problématiques suivantes :
1) L’hétérogénéité des machines ;
2) L’ordonnancement ;
3) La sécurisation des machines ;
4) L’envoi et la réception des données liées aux calculs ;
5) La confidentialité du code exécuté et des données.

Si l’hétérogénéité des pairs ne pose pas forcément de problèmes pour les systèmes de stockage
(le contenu d’un fichier reste le même quel que soit le système de fichier de l’hôte), le calcul en est
quant à lui, très dépendant. Un code est généralement lié à l’architecture des machines : soit il peut
être recompilé (ce qui nécessite le compilateur et les bibliothèques nécessaires), soit il peut être
exécuté directement (scripts, programmes Java en ByteCode).

L’ordonnancement des tâches, autrement dit comment sont attribués les calculs sur les pairs,
doit tenir compte de l’hétérogénéité, ainsi que des propriétés physiques de la machine. Pour
l’hétérogénéité, il suffit que chaque machine puisse être caractérisée dans le système (système
d’exploitation, architecture matérielle). Pour les propriétés physiques, c’est un peu plus complexe :
elles sont variables dans le temps pour chaque machine.

Comme nous l’avons dit précédemment, l’exécution d’un code peut poser des problèmes de
sécurité sur les machines des utilisateurs. Il faut donc trouver des mécanismes pour les sécuriser
(avec des systèmes de bac à sable).

Pour l’envoi et la réception des données, la difficulté est liée à la bande passante nécessaire et
donc, au volume de données échangées. Dans ce cas, des critères de localité sont à prendre en
compte. La solution est généralement de s’assurer que le réseau overlay favorise les liaisons entre les
nœuds physiquement proches.

Le dernier point est le même que pour les systèmes de stockage. Les données qui transitent,
tout comme le code utilisé, peuvent être confidentielles. Un cryptage peut donc être nécessaire.

1.3.4. La communication

Les applications pair-à-pair liées à la communication peuvent être de différents types : il peut
s’agir de messagerie instantanée, de téléphonie, de télévision/radio ou de mise à disposition d’un
contenu (sur le principe du Web).

Dans ce type d’application, le but est de permettre la communication entre les pairs tout en
exploitant leur capacité réseau pour faire transiter le flux global. Comme le montre la Figure 2, pour
diffuser un contenu, les clients doivent se connecter à un serveur qui doit posséder une bande
passante montante suffisante. Le point de vue pair-à-pair est de diffuser le flux vers plusieurs pairs qui
ensuite rediffusent le flux vers d’autres pairs et ainsi de suite. C’est ce principe qui est utilisé par le
logiciel chinois de télévision SopCast.

Outre les problèmes de bande passante à gérer, ce type d’application doit aussi prendre en
compte les problèmes liés à la protection des données et notamment avec la téléphonie (comme
Skype). Pour cela, il faut s’assurer de l’authenticité de l’utilisateur et de la confidentialité des
conversations (avec du chiffrement).

SMB111 4 / 12
 Client

Client

Client
Client

Client
Diffuseur Client
Serveur

Client Client

(a) Client

(b)
Figure 2 : diffusion « centralisée » (a) ou pair-à-pair (b)

1.3.5. DHT et leurs applications

Les DHT (pour Distributed Hash Table, voir le cours sur le nommage) sont plus des outils
qu’une application en tant que telle. Les systèmes pair-à-pair à base de DHT peuvent être vus comme
des couches d’interconnexion entre les nœuds, comme le montre la Figure 3. Au même titre qu’un
intergiciel classique, cette couche permet de structurer les nœuds entre eux. Les DHT sont exploitées
pour stocker les informations sur les nœuds du système (adresse, ressources…). Le protocole basé sur
les DHT permet ensuite de localiser les nœuds ou les ressources d’une manière totalement
décentralisée. Nous avions vu l’exemple de Chord dans le cours sur le nommage.

Application Application Application

P2P

SE SE SE

Figure 3 : la couche pair-à-pair

1.4. Avantages et inconvénients du pair-à-pair

1.4.1. Avantages

Les systèmes pair-à-pair sont devenus très populaires car ils possèdent un grand nombre
d’avantages. Nous pouvons citer par exemple :
- L’accélération des communications ou des échanges : les données transitent directement
entre les sites qui possèdent l’information, sans passer par un serveur quelconque.
- La bande passante du réseau est optimisée car la charge est répartie entre les nœuds du
système.
- La mise en place d’un système pair-à-pair est peu coûteuse, car il ne nécessite pas de
maintenance et les coûts d’infrastructure sont réduits.
- La résistance aux pannes : de par leur conception, les systèmes sont en mesure de gérer la
volatilité des ressources.
- L’extensibilité : le nombre de clients peut dépasser les centaines de millions.
- L’utilisation des ressources inutilisées telles que la puissance de calcul, le stockage ou le
réseau.

Le pair-à-pair 5 / 12
 1.4.2. Inconvénients

Les systèmes pair-à-pair possèdent cependant quelques inconvénients qui ont beaucoup freiné
leur mise en place au sein des entreprises :
- La qualité de service est difficile à mettre en œuvre. Même si les systèmes tels que Skype
fonctionnent très bien, il est difficile d’assurer un service minimal aux clients.
- La fiabilité du système (notamment à cause de la volatilité des clients).
- La sécurité : les systèmes de partage de fichiers sont souvent des vecteurs de virus. De
même, certains systèmes pair-à-pair peuvent compromettre la sécurité au sein d’une
entreprise.
- Le contenu trompeur : la consistance des données mises en partage n’est généralement
vérifiable qu’après coup.
- Le problème du droit d’auteur : les systèmes pair-à-pair peuvent être difficilement régulés
et sont très utilisés pour le téléchargement de fichiers illégaux ou plus généralement, pour
la diffusion de documents sous copyright.

1.5. Classes de systèmes pair-à-pair

Bien souvent, lorsqu’on parle du modèle pair-à-pair, les données sont réparties sur tous les
pairs du système : il n’y a aucune centralisation, évitant ainsi les goulots d’étranglement et un point
critique dans le système. En réalité, il existe plusieurs niveaux de décentralisation qui sont appelés des
classes.

La première correspond aux « systèmes pair-à-pair centralisés ». Ces systèmes possèdent un

serveur central qui contient l’index et les données. Généralement, il est constitué d’un ensemble de
machines : cela permet d’assurer une certaine tolérance aux pannes et une extensibilité (les requêtes
étant alors réparties sur les différents serveurs). Une classe intermédiaire appelée « hybride » permet
de stocker uniquement l’index sur le serveur central et les données sont stockées sur les pairs. Un
exemple de cette solution est Napster (représenté sur la Figure 4 (a)).

Serveur

Index

(a)
(b)
1
Figure 4 : architecture de Napster (a) et représentation d’une vue du réseau Gnutella (b)

La deuxième classe regroupe les « systèmes pair-à-pair purs ». Dans ce cas, il n’y a plus
aucune centralisation, ni de l’index, ni des données. La recherche des informations est plus complexe
et passe généralement par des mécanismes d’inondation comme par exemple Gnutella (représenté sur
la Figure 4 (b)).

La troisième classe correspond aux « systèmes pair-à-pair hiérarchiques » (voir Figure 5). Pour
éviter les problèmes dus à l’inondation, c’est-à-dire un nombre de messages très important et une

1
Image réalisée par Gregory Bray (http://home.comcast.net/~gregory.bray/).
SMB111 6 / 12
surconsommation de bande passante, les pairs sont structurés, généralement sous la forme d’un arbre
(comme KaZaA ou Skype), mais aussi d’un anneau (comme Chord ou Pastry). La notion de super-pair
a été introduite dans KaZaA, puis intégrée dans la version 2 de Gnutella.

29

25
super-pairs
7
22

14
(a) (b)
Figure 5 : systèmes hiérarchiques KaZaa (a) et Chord (b)

2. Étude de cas : Skype

2.1. Description générale

Skype est une application de téléphonie IP : le protocole utilisé est propriétaire, ainsi que le
client. Il a été fondé en 2003 par Niklas Zennström et Janus Friis et développé par trois Estoniens (Ahti
Heinla, Priit Kasesalu et Jaan Tallin), célèbres pour être à l’origine du logiciel KaZaA (d’où les
similitudes dans le mode de fonctionnement). Il est revendu une première fois à Ebay en 2005 pour un
montant de 2,6 milliards de dollars, puis à Microsoft en 2011 pour un montant de 8,5 milliards de
dollars. Il regroupe aujourd’hui plus de 200 millions d’utilisateurs.

Un client doit être installé sur un ordinateur (des clients pour les différents systèmes
d’exploitation sont disponibles). Une fois un compte créé, le logiciel permet ensuite à l’utilisateur de
téléphoner gratuitement, via Internet, à toute personne possédant ce logiciel. Le modèle économique
est essentiellement basé sur les communications payantes : le logiciel permet de contacter aussi des
téléphones fixes ou mobiles, mais l’utilisateur, dans ce cas, doit payer des frais de communication (un
coût plus faible qu’en passant par les opérateurs classiques). D’autres fonctionnalités ont été ajoutées
par la suite.

2.2. Fonctionnement

Skype fonctionne sur le modèle pair-à-pair. Son architecture est représentée sur la Figure 6.
Elle est constituée de quatre éléments différents : le serveur de login (noté LoginServer) qui est en
charge de l’authentification des clients, le serveur d’évènements (noté EventServer) qui joue un rôle
de mise en cache pour les clients connectés, les pairs « normaux » et les super-pairs.

Les deux types de pairs possèdent le même client (qui possède donc les fonctionnalités des
deux types de nœuds), seul leur rôle dans le système est différent. Un pair peut devenir un super-pair
s’il possède des caractéristiques particulières et notamment en termes de bande passante et de
configuration réseau.

Le pair-à-pair 7 / 12
 Figure 6 : architecture de Skype

Le rôle d’un super-pair est de relayer les communications des autres pairs. L’idée est de pouvoir
leur permettre de communiquer même derrière un pare-feu ou un réseau privé. La Figure 7 montre les
deux types de communication possibles :
- Communication directe (représentée en rouge) : les deux nœuds peuvent communiquer
directement entre eux, les super-pairs n’interviennent pas ;
- Communication relayée (représentée en vert) : le super-pair joue le rôle de relai entre les
deux nœuds protégés derrière un pare-feu (ou dans un réseau privé).

Figure 7 : les deux types de communication

2.3. Connexion au réseau

Pour se connecter au réseau, un pair doit nécessairement être connecté à un super-pair. Il

possède ainsi une liste locale des adresses de quelques super-pairs appelée Host Cache. Cependant,
au premier démarrage, cette liste est vide.

La première étape est donc de se connecter à des nœuds particuliers, inscrits en dur dans
l’application : ce sont les Bootstrap Super Nodes. Le client envoie ainsi des paquets UDP à ces
différents nœuds afin de récupérer des adresses de super-pairs. Il peut ensuite se connecter à l’un
d’eux : cette connexion est maintenue tout le long de l’exécution du client. Aux démarrages suivants,
le Host Cache n’est plus vide. Il n’y a donc plus le besoin de passer par les Bootstrap Super Nodes.

L’une des particularités du protocole est d’exploiter plusieurs numéros de ports et différents
protocoles de transport (UDP et TCP). Le client teste les différentes combinaisons jusqu’à trouver la
bonne. Les étapes sont les suivantes :
1) Le client envoie des paquets UDP aux super-pairs connus ;
2) Si aucun ne répond, il réessaie avec une connexion TCP sur l’adresse IP et le port connus ;
SMB111 8 / 12
 3) Si aucune connexion n’est établie, il tente des connexions TCP sur le port 80 ;
4) Idem, mais cette fois-ci en utilisant le port 443 (c’est le port réservé pour HTTPs).

Si au terme de ces quatre étapes, il n’y a aucune connexion, le client réessaie cinq fois avant de
s’avouer vaincu. À noter qu’un super-pair qui refuse la connexion peut lui envoyer une liste d’autres
super-pairs pour l’aider à se connecter.

2.4. Authentification de l’utilisateur

Lorsqu’un nœud est connecté à un super-pair (appelé alors son nœud parent), il doit encore
être authentifié dans le système. C’est par l’intermédiaire du LoginServer que cette étape se déroule.
Dans un souci de redondance, il existe en réalité plusieurs serveurs physiques (les adresses IP sont
spécifiées en dur dans l’application).

Le client contacte directement un LoginServer. Il s’en suit un échange entre les deux afin de
s’assurer de l’identité de l’utilisateur : c’est le principe de clé privée/clé publique qui est exploité. Une
fois cette phase réussie, le serveur envoie, entre autres, des données chiffrées à l’aide d’une clé
privée. Elles sont appelées les SignedCredentials et contiennent les informations du client qu’il peut
ensuite envoyer aux autres clients pour assurer son authenticité : la clé publique associée est stockée
dans le client Skype. Ainsi, la vérification ne passe pas par un serveur, accélérant ainsi les échanges.

2.5. Localisation des utilisateurs

Les super-pairs sont regroupés par slot d’une dizaine, identifié par un entier unique. Lorsqu’un
client est connecté à un super-pair, il est donc connecté à un slot donné et c’est ce qui va permettre
dans la suite de le retrouver (on parle aussi de slot d’activité).

Figure 8 : organisation en slots et recherche d'un contact

Dès que le client s’est authentifié, il doit ensuite prévenir de sa présence. Il demande alors à
son nœud parent de lui envoyer une liste de super-pairs de son slot. Il leur envoie à chacun un
message particulier contenant son identifiant, son adresse IP, ainsi que l’adresse de son nœud parent.
Lorsqu’un de ses contacts souhaite vérifier sa présence, il contacte alors des super-nœuds du slot qui
lui retourne les informations envoyées par le client. Le contact peut alors soit établir une connexion
directe, soit passer par son nœud parent.

2.6. Liste de contacts

La liste des contacts d’un utilisateur n’est pas stockée localement. L’intérêt est de pouvoir
utiliser le même compte sur des machines différentes. La liste est donc sauvegardée sur les
EventServer. Une fois le client connecté (c’est-à-dire authentifié et enregistré auprès de plusieurs

Le pair-à-pair 9 / 12
super-pairs), il en contacte un (ou plusieurs s’il ne reçoit aucune réponse). Après une étape de
vérification (pour valider l’authenticité des deux intervenants), la liste est envoyée au client.

Une fois la liste connue, il reste à vérifier si les contacts de la liste sont présents ou non (ce qui
permet de mettre à jour leur statut). Pour cela, des requêtes sont effectuées vers les super-pairs du
slot correspondant au contact. Le pair passe par son nœud parent en lui demandant une liste de cinq
super-pairs du slot désiré (voir Figure 8, flèche 1). Il envoie ensuite des messages à ces super-pairs
pour retrouver l’annonce que le client avait fait (voir Figure 8, flèche 2). À partir de cette annonce, il
récupère l’adresse IP du client ou de son nœud parent. Il peut alors envoyer un ping soit directement
au pair s’il n’est pas derrière un pare-feu ou dans un réseau privé, soit via son nœud parent (voir
Figure 8, flèches 3).

2.7. Évolutions et conclusion

L’ensemble des informations connues sur le fonctionnement de Skype et de son protocole a été
dans un premier temps issu de la technique de reverse engineering. C’est pour cette raison que
certaines parties du protocole sont assez méconnues (pour rappel, les données qui transitent entre les
pairs sont chiffrées, rendant la technique de reverse engineering difficile).

Depuis le rachat de Skype par Microsoft, de nombreuses rumeurs ont circulées sur le Web et il
n’est pas simple de faire le tri entre le vrai et le faux. Ainsi, il a été dit que Microsoft, dans un souci de
qualité (de contrôle pour d’autres), avait mis en place des serveurs pour jouer le rôle de super-pairs,
évitant ainsi des problèmes de connexion. En tout cas, ce qui est sûr, c’est que Microsoft a prévu dès
2013 d’intégrer le célèbre MSN (pour Microsoft Messenger) au sein du logiciel et que les deux comptes
seraient alors fusionnés.

Skype et son succès incontestable ont entraîné l’apparition de quelques concurrents. En termes
de nombre d’utilisateurs, ils ne le détrônent pas pour le moment. D’autre part, l’IETF a proposé un
draft nommé P2PSIP dont le but est de spécifier une version P2P du protocole SIP (pour Session
Initiation Protocol), destiné en partie à la voix sur IP. Et son principal avantage est qu’il sera ouvert.

3. Références/bibliographie

[1] http://www.sopcast.com/ : le site officiel de SopCast.

[2] http://www.skype.com/ : le site officiel de Skype.

[3] http://www1.cs.columbia.edu/~salman/skype/ : de nombreux articles traitant de Skype (en

anglais).

SMB111 10 / 12
4. Exercices

4.1. QCM

1. Le logiciel nécessaire pour se connecter à un système pair-à-pair est appelé un pair :

 Vrai  Faux
2. Le réseau overlay correspond à un réseau virtuel :
 Vrai  Faux
3. L’anneau de Chord est un réseau overlay :
 Vrai  Faux
4. Un système pair-à-pair peut posséder des clients différents :
 Vrai  Faux
5. Un protocole pair-à-pair est ouvert :
 Vrai  Faux
6. Skype est un système décentralisé :
 Vrai  Faux

4.2. Exercice

Nous souhaitons réaliser une application de partage de fichiers (il n’est pas question ici de
développer cette application, mais de réfléchir à sa modélisation et aux problématiques liées aux
systèmes pair-à-pair). L’architecture générale de l’application est représentée sur la figure suivante :

pair pair pair

serveur
Figure 9 : architecture générale de l'application

Un pair possède un répertoire contenant une liste de fichiers. Il doit être en mesure de
télécharger un fichier depuis tous les autres pairs et permettre le téléchargement de ses propres
fichiers. Chaque pair est identifié par un nom unique. Nous supposons disposer d’un serveur dont le
but est précisé dans la suite.

1. Centralisation de la connaissance. Nous souhaitons que le serveur conserve les

informations sur les clients et le nom des fichiers qu’ils possèdent.
a. Indiquez quels sont les échanges entre les pairs. Pour chaque, précisez les intervenants
et quelles sont les données échangées. Vous indiquerez quelles données doivent être
conservées sur les pairs et le serveur.
Le pair-à-pair 11 / 12
 b. Quels problèmes ce mode de fonctionnement apporte-t-il quant à la tolérance aux
pannes ? Et à la charge des entités ?
c. Quel rôle le serveur peut-il jouer si des pairs sont situés derrière un pare-feu ?
2. Limitation de la connaissance. Nous souhaitons que la liste des fichiers ne soit plus connue
sur le serveur.
a. Quelles sont les modifications par rapport aux questions précédentes (1.a et 1.b) ?
b. Que se passe-t-il si un pair se déconnecte ? Comparez par rapport à la solution
précédente.
3. Décentralisation. Nous souhaitons ne plus utiliser le serveur.
a. Quelles sont les problématiques apportées par cette solution ? Comment y répondre ?
b. Concernant la gestion du réseau overlay, quelles solutions connaissez-vous ?

SMB111 12 / 12