Implémentation d`une infrastructure P2P eDonkey

Transcription

AUBERT Cédric
DI GIACOMO Marion
JAZZA Lahoucine
MAX Mathieu
Implémentation d'une infrastructure P2P
eDonkey
Automne 2008
AUBERT Cédric - DI GIACOMO Marion - JAZZA Lahoucine – MAX Mathieu
TABLE DES MATIERES
Introduction
I.
Etude de l’infrastructure peer to peer générale ............................................................................. 4
A.
Le modèle du réseau Peer 2 Peer ............................................................................................ 4
1.
Principe ................................................................................................................................ 4
2.
Avantages et inconvénients ................................................................................................. 4
3.
Domaines d'application ....................................................................................................... 6
4.
Les différentes architectures ............................................................................................... 6
B.
II.
Le protocole eDonkey .................................................................................................................. 8
Implémentation de l’infrastructure P2P edonkey........................................................................... 9
A.
Architecture et logiciels utilisés dans notre étude .................................................................. 9
1.
Architecture matérielle........................................................................................................ 9
2.
Logiciels utilisant le réseau edonkey ................................................................................. 10
B.
Installation et configuration d’eserver Lugdunum .................................................................... 10
C.
Utilisation de Wireshark, détection des trames EDONKEY ................................................... 13
III.
Etude du protocole edonkey......................................................................................................... 15
A.
Communication entre un client et un serveur ...................................................................... 15
1.
Connexion d’un client à un serveur (HighID, LowID) ......................................................... 15
2.
Mise à jour des différentes informations (listes de serveurs…)......................................... 19
3.
Recherche et obtention d'une liste d'ID de téléchargement............................................. 23
B.
Communication entre deux clients............................................................................................ 25
1.
Mécanisme de call-back dans le cas d’un client LowID ..................................................... 25
2.
Téléchargement d’un fichier entre deux clients ................................................................ 27
3.
Gestion des files d’attente ................................................................................................. 35
Conclusion
ANNEXE : Compte-rendu de la réunion organisée avec M.ABDELOUAHAB Mahdi Amine et M.HATAHET
Sinan.
Page 2
Introduction
Notre projet consiste à mettre en place une infrastructure peer to peer se basant sur le
protocole edonkey et étudier ce protocole. Pour cela nous avons utilisé plusieurs machines reliés par
un routeur. Les analyses de traces sous Wireshark nous ont permis d’identifier les principales
caractéristiques du protocole edonkey.
Tout d’abord nous présenterons l'infrastructure P2P en général. Nous expliquerons le modèle
du réseau P2P en précisant son principe, ses avantages et inconvénients, ses domaines d'application
et les différentes architectures du P2P. Ceci est une première vue général de ce qui existe aujourd’hui
dans le P2P. Puis nous expliquerons le contexte dans lequel nous avons travaillé c'est-à-dire la
architecture matérielle et logicielle qui nous a permis d’effectuer une étude minutieuse sur certains
points du protocole edonkey, ceux-ci seront expliqués dans une dernière partie. Nous tenons à
préciser que la recherche documentaire a été difficile car il existe peu de ressources concernant le
protocole edonkey. En effet pour comparer les différents résultats que nous avons obtenus, nous
nous sommes basés sur un seul et unique document qui est la référence sur le protocole edonkey :
Nous tenons à remercier M.ABDELOUAHAB Mahdi Amine et M.HATAHET Sinan qui nous ont
accueillis dans leur bureau afin de répondre à nos questions et qui nous ont permis d’étudier d’autres
points du protocole edonkey. Vous trouverez en annexe le compte rendu de cette réunion.
Page 3
I.
ETUDE DE L’INFRASTRUCTURE PEER TO PEER GENERALE
A. Le modèle du réseau Peer 2 Peer
1. Principe
Le terme « Peer-to-Peer » (traduit « poste à poste » ou « pair à pair » en français) désigne un
modèle de réseau informatique dont les éléments, appelés « nœuds » ou « peer », sont à la fois
clients et serveurs lors des échanges.
Ce modèle s'oppose strictement au modèle client-serveur. En effet, dans ce type d'architecture, la
ressource demandée n'est disponible qu'en un point central du réseau et les clients ne sont que des
demandeurs de cette ressource.
Au contraire, dans le modèle P2P, cette séparation est levée : on ne parle ni de client, ni de serveur. Il
n'existe que des pairs. Tous les pairs ont la ressource et tous les pairs la demandent. On peut aussi
considérer les pairs du réseau comme étant à la fois client et serveur.
Comme leur nom l’indique, les Peer-to-Peer permettent d’établir des communications directes, d’égal
à égal, entre les différents nœuds du réseau, qui peuvent alors échanger différents types
d’informations sans passer par un serveur central.
Ce modèle a permis une décentralisation des réseaux en offrant une alternative aux traditionnelles
architectures client-serveur ou aux architectures N-tiers.
Voici un schéma mettant en évidence la différence de topologie entre les deux modèles :
Napster, apparu en juin 1999, est considéré comme le premier P2P, même s'il possédait une
architecture centralisée. C'est en effet le premier logiciel d'échange à avoir connu un succès mondial.
2. Avantages et inconvénients
Dès leur apparition, les P2P se sont distingués des architectures traditionnelles grâce à leurs
nombreux avantages :
Page 4
•
La répartition de la charge :
Les échanges sont gérés directement par les pairs, ce qui élimine un des principaux
problèmes des architectures clients-serveurs, c'est-à-dire la répartition de la charge. On n'a
pas ici le problème de congestion des réseaux qui peuvent se produire autour d'un serveur
central devant répondre à de très nombreuses demandes.
Chaque pair gère ses propres données et répond aux requêtes des autres pairs.
•
La capacité de stockage :
Chaque nœud ne possède qu'un ensemble très restreint des données du réseau. L'ensemble
des nœuds partage leurs données avec les autres ordinateurs.
La capacité de stockage est ainsi infiniment supérieure à celle d'un serveur traditionnel,
suivant le modèle client-serveur, qui ne pourrait pas supporter une quantité
d'informations aussi importante.
•
La puissance de calcul :
L'ordinateur d'un utilisateur utilise moins de 20% de sa puissance de calcul.
Une application répartie basée sur la technologie Peer-to-Peer peut donc permettre de
mutualiser cette puissance non utilisée pour des recherches demandant des capacités
considérables, qu'un serveur isolé ne peut posséder.
•
Résistance aux pannes :
Les données sont présentes sur de nombreux postes différents.
Il est donc possible d'effectuer facilement des sauvegardes réparties à travers le réseau.
Cela évite de perdre des informations et de mettre en place de lourds systèmes de
sauvegardes.
•
Extensibilité :
Les pairs se configurent automatiquement.
Il est très facile de rajouter de nouveaux pairs et ceux-ci sont gérés dynamiquement.
Le P2P a aussi quelques inconvénients :
•
Pas de centralisation des données :
Dans l'architecture client-serveur, on sait que c'est le serveur qui possède la ressource. En
P2P, on sait que plusieurs éléments du réseau ont la ressource, mais on ne sait pas lesquels.
•
Difficulté de conception :
D'une façon générale, les applications P2P sont beaucoup plus difficiles à concevoir qu'une
application de type client-serveur.
Page 5
3. Domaines d'application
Le P2P a de nombreux usages. Il est principalement utilisé par le grand public, dans des
usages techniques, ou dans la recherche.
On distingue particulièrement :
•
Le partage de fichiers :
Chaque internaute est un pair du réseau et les ressources sont des fichiers. Chacun peut donc
partager ses fichiers et télécharger les fichiers des autres. Ces systèmes s'avèrent très
efficaces y compris quand il s'agit d'échanger des données de gros volumes.
Parmi les applications les plus utilisées, on peut distinguer Bittorrent et eMule, que l'on a
étudié plus loin.
•
Le calcul distribué :
Les ordinateurs d'aujourd'hui sont tellement puissants que la majeure partie du temps, une
grande partie de leur processeur est disponible pour effectuer des calculs. Le projet BOINC a
saisi cette opportunité pour créer un gigantesque parc informatique réparti dans le monde
afin d'utiliser cette immense puissance de calcul total pour effectuer des calculs trop
complexes pour être réalisé dans un laboratoire.
•
Autres applications :
D’autres applications telles que la messagerie instantanée (ICQ, AIM) ou encore la
visioconférence profitent des avantages techniques du P2P. Il y a aussi une application dans
le domaine de la voix sur IP. En effet, certaines sociétés de télécommunications commencent
à s’intéresser au P2P pour désengorger leurs serveurs téléphoniques.
4. Les différentes architectures
•
Les Peer-to-Peer structurés :
Ils sont basés sur l'établissement d'une DHT (Distributed Hash Table) permettant d'ajouter
les nouveaux nœuds dans le réseau. Chaque nœud reçoit une liste des voisins avec lesquels il
pourra communiquer. La liste des voisins est dite logique, car ceux-ci peuvent se trouver à
l'autre bout du monde. Chaque pair est responsable d'une partie spécifique du contenu du
réseau. Il est possible de faire des recherches avec un nombre de messages croissant de
façon logarithmique.
•
Les Peer-to-Peer non structurés :
Ils possèdent des liens entre les nœuds qui sont établis de manière arbitraire. Le protocole
eDonkey, que nous allons ensuite étudier, est basé sur ce type d'architecture.
Il est possible de classifier ces réseaux P2P d'une autre manière.
•
Les Peer-to-Peer centralisés :
Dans ce type d'architecture, il y a un serveur central, gérant l'identité des utilisateurs,
l'indexation des partages, les recherches et la mise en relation des pairs : le serveur donne à
chaque client l'adresse des pairs possédant le fichier recherché. Le client se connecte alors à
ce pair pour échanger directement les données. Les fichiers ne passent donc pas par le
serveur.
L'index est donc centralisé, mais les fichiers sont décentralisés.
Page 6
•
Les Peer-to-Peer hybrides :
Dans cette architecture, il y a des nœuds spéciaux appelés « super-peer ». Ces nœuds
indexent les fichiers partagés et servent d'intermédiaire pour les nœuds qui leur sont
rattachés. Les serveurs utilisés dans eDonkey2000 peuvent être vus comme des super-peers.
En effet, eDonkey2000 est constitué de très nombreux serveurs spécialisés communiquant
entre eux et servant d'intermédiaire pour les clients.
•
Les Peer-to-Peer « purs » :
Ce sont les réseaux totalement décentralisés. L'ensemble des nœuds sont égaux et jouent le
même rôle.
Chaque pair gère donc les recherches et le partage, sans passer par un serveur central
ou des super-peers, en utilisant en général des techniques des algorithmes spécifiques.
En classifiant les architectures de cette manière, on peut se rendre compte de certaines
lacunes. En effet, si on utilise par exemple une architecture de type centralisé, il suffit de bloquer le
serveur central pour bloquer le réseau dans son intégralité.
Page 7
B. Le protocole eDonkey
Le protocole eDonkey se situe dans l'architecture hybride. On a donc un ensemble de
serveurs (super-peers) et de clients (peers) communiquant entre eux.
Les serveurs permettent de gérer l'indexation des données, les recherches et la mise en
relation des utilisateurs pour commencer les échanges.
eDonkey permet uniquement l'échange de fichiers. Son principal atout est de pouvoir
partager les parties de fichiers dont on dispose tout en continuant de le télécharger.
•
Les serveurs ED2K :
Ils sont les points d'entrée du réseau. Ils permettent de se faire connaître sur le réseau et
d'en connaître d'autres. Il est alors possible d'indexer l'ensemble des fichiers des clients
connectés et ainsi de leur proposer un moteur de recherche.
•
Les clients :
Ce sont les éléments les plus importants dans le réseau eDonkey. Le rôle du client est de :
se connecter à un serveur pour indiquer ce qu'il partage
émettre des requêtes de recherche de fichiers
demander les sources possibles pour un fichier demandé
télécharger les fichiers demandés sur les sources
vérifier l'intégrité et la corruption des fichiers
envoyer les fichiers demandés par les autres clients
gérer une file d'attente des clients
proposer une interface graphique efficace
Nous utiliserons eMule et Shareaza dans notre phase expérimentale.
Nous avons abordé dans cette partie le principe des réseaux P2P et ses caractéristiques, les
différentes technologies qui ont été développés dans ce domaine, et tout ce qui se fait aujourd’hui à
l’aide de cette technologie. Nous allons maintenant nous intéresser plus concrètement au protocole
edonkey dans une partie expérimentale.
Page 8
II.
IMPLEMENTATION DE L’INFRASTRUCTURE P2P EDONKEY
Notre étude porte sur le protocole edonkey. Afin de l’étudier nous avons défini au début de
notre étude une architecture qui nous a permis d’effectuer diverses analyses à partir de scénarii.
Dans un premier temps nous allons présenter l’architecture matérielle que nous avons mise en place
pour les analyses de traces du protocole, puis nous détaillerons l’installation et la configuration du
serveur edonkey eserver Lugdunum et enfin nous préciserons le logiciel utilisé pour nos analyses et
sa configuration pour une bonne compréhension des trames du protocole edonkey.
A. Architecture et logiciels utilisés dans notre étude
1. Architecture matérielle
Afin d’étudier les caractéristiques du protocole edonkey, nous avons mis en place une
architecture contenant 3 PC relié à un routeur. Nous avons utilisé aussi une machine virtuelle à l’aide
de virtualBox, cette machine est considéré comme une 4ème machine dans notre réseau, elle possède
une adresse IP différente de celle de la machine hôte. Sur cette machine est installé le système
d’exploitation Linux Debian Etch 4.0. Elle nous est utile dans le sens où notre serveur edonkey plus
précisément eserver Lugdunum fonctionne sur cette machine.
Voici le schéma de notre architecture :
Page 9
2. Logiciels utilisant le réseau edonkey
Il existait deux principaux serveurs pour le réseau peer-to-peer eDonkey2000. Le premier était
le serveur original de la société MetaMachine à l’origine du réseau eD2k. Il s’agissait d’un serveur
propriétaire écrit en C++ dont les sources sont restées privées. Le second était eserver que l’on doit à
une personne connue sous le pseudonyme « Lugdunum ». Écrit en C à partir de rien, il était
également propriétaire et ses sources sont restées privées, bien qu’il était disponible gratuitement
sur le site http://lugdunum2k.free.fr/ (qui n’existe plus). Actuellement, ces deux logiciels ne sont plus
maintenus et la plupart des serveurs eD2k encore en activité utilisent eserver.
Le réseau eD2k est rapidement devenu très populaire à ses débuts est l’est encore à l’heure
actuelle. Ainsi, il existe toujours de nombreux clients pouvant exploiter le réseau eD2k.
Le client original, gratuit mais propriétaire et aux sources privées, était le logiciel eDonkey2000 de la
société MetaMachine. Il n’est plus maintenu aujourd’hui mais sa dernière version (1.4.5 officielle ou
1.4.6 en août 2006) peut encore être trouvée, quoique difficilement.
Le client eDonkey le plus populaire est néanmoins le client libre eMule pour Windows. Le
projet eMule a débuté en 2002 à l’initiative de Hendrik Breitkreuz (« Merkur ») qui était mécontent
du client officiel. Merkur s’est par la suite retiré du projet, mais ce dernier est toujours bien actif.
eMule a largement contribué au succès du réseau eD2k créé par la société MetaMachine, même s’il
faut savoir qu’il s’agissait d’un concurrent d’eDonkey2000 et que ses utilisateurs n’étaient donc pas
des clients de MetaMachine (95% de clients eMule contre 5% de clients eDonkey). De nombreux
autres clients basés sur eMule existent.
Le logiciel Shareaza, que nous avons aussi utilisé avec eMule, est un client multi-protocole qui
prend en charge le réseau eD2k (en plus de Gnutella 1 et 2, et BitTorrent).
Avec le nombre important de clients non officiels pour le réseau eD2k et l’importante
considérable de certains d’entre eux (eMule), des extensions au protocole eD2k original de la société
MetaMachine sont apparues. En fait, l’ensemble des clients communiquent entre eux et avec les
serveurs en utilisant le protocole eD2k de base : c’est leur langage commun. Mais lorsque deux clients
identiques rentrent en contact - par exemple des clients eMule - ils peuvent s’échanger des messages
spécifiques car ils se comprennent mutuellement ; le protocole eD2k original est ainsi « étendu ». En
revanche, si un client eMule rencontre un client Shareaza, ils devront communiquer selon le
protocole original. C’est pour cette raison que nous avons utilisé Shareaza. A noter que certains
clients sont compatibles avec les extensions protocolaires d’eMule tellement celui-ci est répandu.
Nous aurions bien voulu utiliser le client original eDonkey2000 pour notre expérimentation mais nous
n’avons pas réussi à le faire fonctionner.
B. Installation et configuration d’eserver Lugdunum
Pour notre étude expérimentale, nous avons choisi d’utiliser le serveur Lugdunum dans sa
dernière version 17.15 que nous avons récupérée via le réseau eD2k avec le client eMule. Nous avons
fait tourner ce serveur sous le système d’exploitation GNU/Linux (Debian Etch) installé sur une
machine virtuelle (créée avec VirtualBox). Le système hôte de la machine réelle était Windows XP.
N.B. : Il existe également un serveur nommé Donkey Control pour Windows que l’on peut trouver
facilement sur le web, mais il ne s’agit en fait que d’une interface graphique au serveur Lugdunum
(consulter le fichier readme.txt).
Page 10
Le serveur Lugdunum se présente sous la forme d’un simple fichier exécutable que nous
placé dans un répertoire nommé Ludgunum. Il est accompagné de quelques autres fichiers :
• donkey.ini : un fichier de configuration lu au lancement du serveur ;
• ipfilter.dat
• ip-to-country.csv
• serverList.met : un fichier contenant les adresses d’autres serveurs eDonkey.
[server]
name=Le serveur eDonkey à Mathieu
desc=A little server for the donkey network
maxClients=1000
public=true
#
console=true
logFile=false
verbose=false
vverbose=false
bverbose=false
#
welcome[1]=> Welcome on my server
welcome[2]=> You are now connected.
welcome[3]=> Coucou
welcome[4]=> Lugdunum esever v17.15 running on Debian Etch
#
# replace this ip by a valid one if need.
# (this is donkey server 2 ip, online in june 2007)
#seedIP=62.241.53.16
#seedPort=4242
#
type=key
############# YOUR PUBLIC IP HERE
thisIP=192.168.1.4
port=4242
#
LOWIDenable=1
LOWIDpercent=15
maxservers=512
hardLimit=5000
softLimit=4000
trackemule=0
warnfakes=1
autoservlist=/home/mathieu/Lugdunum/serverList.met
max_clients_per_ip=10
maxSearchCount=250
#
On y trouve quelques paramètres immédiatement utiles :
• name : le nom du serveur qui apparaît dans le logiciel client ;
• desc : la description du serveur (qui apparaît également dans le logiciel client) ;
• maxClients : le nombre maximal de clients que le serveur peut accepter simultanément ;
• welcome[x] : le message de bienvenue envoyé par le serveur à un client qui se connecte ;
• thisIP : l’adresse IP du serveur ;
• port : le port sur lequel le serveur écoute et accepte les connexions des clients ;
• LOWIDenable : un booléen (0 ou 1) indiquant si le serveur accepte des clients en LowID ;
• autoservlist : le chemin du fichier contenant la liste des autres serveurs connus ;
• max_clients_per_ip : le nombre maximal de clients ayant la même adresse IP.
Page 11
Le serveur Lugdunum possède une interface en ligne de commande (permet par exemple de voir
le nombre de clients connectés, etc.) :
Page 12
C. Utilisation de Wireshark, détection des trames EDONKEY
Pour étudier le protocole Edonkey, nous avons analysé les trames à l’aide de l’outil d’analyse
de protocoles réseaux Wireshark.
Lorsqu’on effectue une capture sous ce logiciel, on obtient toutes les trames du trafic réseau.
On a donc besoin de sélectionner les trames qui nous intéressent afin de pouvoir les étudier. En effet
lors de l’utilisation du client Emule effectuant une requête vers le serveur, nous obtenions par
exemple la capture suivante :
On remarque ici que Wireshark
détecte le paquet sélectionné
comme un paquet TCP contenant
des données. Or ces données
commencent par e3. Ce qui
correspond à l’ID du protocole
Edonkey.
Page 13
Afin de faciliter l’analyse de telles trames, Wireshark permet de les décoder et de retrouver
alors la vraie nature du paquet transmis.
Il suffit de cliquer sur le bouton droit de la souris sur le type de trame que l’on veut décoder,
on sélectionne ensuite l’Item « Decode As », dans l’onglet « Transport », on choisit alors le protocole
correspondant aux trames (ici EDONKEY), on valide et applique un filtre sur les trames « edonkey »,
nous obtenons alors toutes les échanges qui ont été effectué par le protocole Edonkey :
Page 14
III.
ETUDE DU PROTOCOLE EDONKEY
Nous avons étudié de nombreux points importants sur le protocole edonkey, d’autres par
contre non pas été traités, ceux-ci étaient moins important et plus difficile à mettre en œuvre d’un
point de vue expérimental, le manque de ressource documentaire a beaucoup joué aussi sur notre
étude. Néanmoins nous pouvons dire que notre étude est très étoffée.
A. Communication entre un client et un serveur
1. Connexion d’un client à un serveur (HighID, LowID)
•
Cas d’attribution d’un HighID
Ayant effectué notre étude expérimentale dans un réseau local, nous n’avons jamais eu de
problème pour que notre client obtienne un HighID, en effet pas de NAT, et les firewalls ont été
configurés afin de ne pas bloquer les ports du client.
Nous avions vu lors de la recherche documentaire que la connexion entre un client et un
serveur s’effectuait ainsi dans le cas d’une obtention d’un HighID :
Nous allons maintenant montré que cela représente bien une connexion entre un client et un
serveur. Dans notre capture, 192.168.1.4 représente le client et 192.168.1.13 le serveur.
Page 15
Frame 6 – 9 : Ces trois paquets correspondent à une connexion standard établie vers le serveur. Cette
conversation a été coloriée en vert. La connexion établie, le client envoie alors un message
Login/Hello de type 0x01.
Frame 10 – 15 : C’est alors au tour du serveur d’instancier une connexion vers le client afin de
déterminer si le client accepte les connexions entrantes, c'est-à-dire il détermine si de futurs clients
vont pouvoir se connecter directement à ce client. Si cela est possible, il attribuera alors un HighID
qui correspond à l’adresse IP du client ayant subi des décalages comme expliqué dans la deuxième
partie de ce présent rapport. Lorsque la connexion avec le client est établie, il envoie lui aussi un
message de type HELLO, le client répond par un message de type HELLO ANSWER. Tout va bien, le
serveur va pouvoir attribuer un HighID au client, il ferme alors la connexion qu’il a ouverte avec le
client. La suite des échanges se déroule sur la connexion établie par le client.
Frame 16 : Le serveur envoie un message de type ID_CHANGE au client qui contient le HighID
attribué.
•
Cas d’attribution d’un LowID
Le cas où le serveur attribue un LowID à un client se produit lorsque le serveur ne peut
instancier une connexion TCP vers ce client. Nous avons reproduit ce scénario en appliquant la règle
IPTABLES suivante :
iptables –t filter –A OUTPUT –p tcp --dport 4662 –j DROP
On interdit ainsi les paquets sortant au niveau du serveur de type TCP avec le port de destination
4662 qui est le port sur lequel écoute le client. La tentative de connexion échouera donc et le serveur
attribuera un LowID au client.
Page 16
Dans un tel cas, les échanges ont été déduits ainsi :
Les analyses de traces que nous avons effectuées confirment ces échanges :
Frame 1 – 3 : Connexion TCP standard du client au serveur.
Frame 4 : envoi du message Hello par le client.
Ici on ne voit pas la tentative de connexion de la part du serveur, car on l’a interdit au niveau système
d’exploitation Debian Etch grâce à la règle IPTABLES vu ci-dessous.
Frame 8 : La connexion entrante avec le client étant impossible, il renvoie par le biais de la connexion
instanciée par le client un message de type SERVER MESSAGE indiquant au client qu’il aura un LowID :
Frame 10 : Le serveur fait parvenir ce LowID de la même façon que pour le HighID, c'est-à-dire par le
message de type ID CHANGE.
Page 17
Le LowID attribué ici au client est 2.
•
Cas d’un serveur plein
Il se peut qu’un serveur soit limité en nombre de connexion. Dans ce cas lorsque le client
fournit son login, le serveur envoie un message expliquant la raison de son refus et ferme alors la
connexion TCP.
Nous avons pour cela mis en place un scénario assez simple. Nous avons configuré notre serveur pour
qu’il n’accepte aucune connexion. Pour cela nous modifions le fichier de configuration donkey.ini en
mettant maxClients=0. Ainsi tout client sera rejeté.
Frame 3 – 5 : Connexion TCP standard
Frame 6 : message Login/Hello du client vers le serveur.
Frame 7 : Le serveur n’accepte aucune connexion, c’est le même cas lorsqu’il atteint le nombre
maximale de connexions autorisées. Il envoie un message de type SERVER MESSAGE avec la raison de
se son refus.
Page 18
La raison évoquée est : « Le serveur est plein ».
Dans ce paquet TCP nous trouvons alors le flag FIN à 1. Le serveur se déconnecte du client.
2. Mise à jour des différentes informations (listes de serveurs…)
Suite à la connexion du client, celui-ci va envoyer divers messages afin de transmettre au
serveur les fichiers qu’il veut partager avec d’autres clients, recevoir de la part du client une liste de
serveurs pour qu’il puisse mettre la sienne à jour, et des informations sur le serveur même. Ces
messages s’effectuent de la manière suivante :
Nous avons trouvé une petite différence avec ce modèle, nous allons l’expliquer grâce aux analyses
de traces que nous avons effectuées.
Page 19
Nous pouvons déjà remarquer que deux clients sont connectés au serveur : les machines 192.168.1.4
et 192.168.1.2.
Frame 13 : Nous pouvons voir que le serveur envoie le message SERVEUR STATUS dans le même
paquet que celui d’ID_CHANGE et non pas après une demande de la liste des serveurs de la part du
client. Le message SERVEUR_STATUS renseigne le client sur le nombre de connectés au serveur et le
nombre de fichiers disponible :
Frame 16 : le client va envoyer au serveur la liste des fichiers qu’il veut partager avec d’autres clients.
Ce message est de type OFFER FILE. Ici notre client possède 4 fichiers à partager.
Page 20
Frame 18 : Le client va ensuite demander au serveur de lui transmettre la liste de serveurs qu’il
contient afin de mettre à jour sa propre liste. Le message est de type GET SERVER LIST.
Ici nous pouvons voir que nous n’avons pas de réponse de la part du serveur, en effet nous avons
pourtant fourni un fichier serverList.met et server.met non vide mais aucun message SERVER LIST de
la part du serveur. En se connectant directement avec le serveur edonkeyServer No1, nous avons pu
voir cette réponse, elle fournit les adresses IP des différents serveurs ainsi que les numéros de port
sur lesquels ils écoutent.
Frame 20 : Le serveur envoie ensuite des informations le concernant, ce sont de simples chaînes de
caractères, le message est de type SERVER INFO DATA ou encore SERVER IDENTIFICATION comme
marqué plus haut dans le schéma :
Page 21
Frame 25 : Dans le cas où des téléchargements sont en cours mais non pas été terminés, lorsque le
client se reconnecte à un serveur, il va tout de suite redemander des sources pour le fichier
incomplet, si aucun téléchargement n’était en cours, alors nous n’aurions pas les deux paquets
suivants. Ce message est de type GET SOURCES, il comporte simplement le hash du fichier dont on
veut connaître les sources pour pouvoir reprendre le téléchargement. Dans certaines captures que
nous avons effectué, nous avons remarqué deux types de messages ayant le même rôle : GET
SOURCES avec pour ID 0x19 et GET SOURCES OBFUSCATION avec pour ID 0x23. Nous n’avons pas
compris la différence entre ces deux messages.
Frame 26 : La réponse du serveur est un message de type FOUND SOURCES d’ID 0x42, comme
précédemment nous avons trouvé un autre message FOUND SOURCES OBFUSCATION d’ID 0x44. Ce
message contient les adresses IP où le fichier demandé est disponible. Le client récupérera ces
adresses et pourra se connecter directement au client possédant le fichier. Ici le serveur nous indique
que le fichier n’est disponible que chez l’adresse IP 192.168.1.2 sur le port 6346.
Ces échanges terminés, nous pouvons dire que le client s’est connecté correctement au serveur et a
reçu toutes les informations nécessaires pour effectuer une recherche et télécharger divers fichiers.
Nous allons détailler maintenant les échanges permettant cette recherche.
Page 22
3. Recherche et obtention d'une liste d'ID de téléchargement
Les documents que nous avons pu trouvés nous indiquent que la recherche à partir d’un
client d’un fichier se fait selon les échanges suivants :
Nos analyses de traces permettent de mieux comprendre ces échanges. A partir d’un client,
nous voulons télécharger par exemple la musique « machin.mp3 ». Celle-ci se trouve sur un autre
client connecté aussi sur le serveur. Notre recherche s’effectue par le mot clé « machin ».
Notre capture se présente ainsi :
Frame 29 : Nous pouvons voir un message de type SEARCH FILES, le client envoie tout simplement au
serveur le mot clé avec ce type de message.
Page 23
Frame 30 : le serveur recherche alors dans la liste de fichiers que tous les clients partagent si un ou
plusieurs fichiers contiennent le mot « machin », il trouve la musique « machin.mp3 ». Il renvoie alors
un message au client de type SEARCH FILE RESULTS contenant les adresses IP et ports des clients qui
possèdent un fichier dont le nom matche le mot clé envoyé précédemment. Le message présente
aussi toutes les caractéristiques utiles sur le fichier (hash, nom, taille, disponibilité). L’obtention du
hash par le client est ici très importante, en effet il se peut que le contenu demandé se trouve chez
un autre client mais sous un autre nom. Cette source supplémentaire n’est pas mentionnée dans ce
message, c’est une capacité de téléchargement en moins pour le client. Nous allons voir comment
récupérer cette source dans la frame suivante. En effet dans notre scénario nous avons un client
possédant cette musique sous le nom « viva la vida ». Nous voyons bien que cette source n’est pas
répertoriée lors de la recherche.
Nous voyons bien ici qu’une seule source est transmise au client.
Frame 53 : Afin de récupérer toutes les sources sur un fichier, le client va envoyer au serveur un
message de type GET SOURCES, il transmet juste ici le hash du fichier et non le nom, ainsi si sur
plusieurs clients il existe le même contenu mais dont le nom diffère, le hash permettra d’identifier
tous les fichiers qui ont le même contenu. Le client veut télécharger la musique « machin.mp3 », il
demande au serveur tous les fichiers ayant pour HASH : 501F8738BD02426E0EB9B38B04739A.
Page 24
Frame 54 : Le serveur renvoie alors une liste de clients qui possèdent le fichier ayant le même hash
par un message de type FOUND SOURCES. Le client a alors en sa possession toutes les adresses IP sur
lesquels il va pouvoir faire une requête de téléchargement, le client va pouvoir télécharger des
parties de fichier chez le client possédant le fichier « viva la vida.mp3 », le téléchargement de
« machin.mp3 » sera donc plus rapide. Grâce au hash, toutes les sources sont utilisées.
Conclusion : Cette première partie nous a permis de comprendre comment un client pouvait se
connecter avec un serveur et récupérer les adresses IP et port des clients qui possèdent le fichier que
le client veut télécharger, il a maintenant toutes les informations nécessaires pour pouvoir se
connecter directement à un autre client et demander le téléchargement du fichier voulu. Nous allons
voir maintenant comment s’effectue les échanges entre deux clients lors du transfert de fichiers.
B. Communication entre deux clients
1. Mécanisme de call-back dans le cas d’un client LowID
Avant d étudier minutieusement les échanges entre deux clients lors d’une demande de
téléchargement de l’un à l’autre, nous allons nous intéresser au mécanisme de call-back.
Comme nous avons pu le voir précédemment, le serveur attribue un LowID à un client s’il est
impossible pour lui d’établir une connexion entrante vers ce client. Ainsi deux clients possédant un
LowID ne pourront jamais s’échanger de données (cela pourrait se faire en faisant passer tout le
trafic par l’intermédiaire du serveur, mais cela demande trop de ressources pour que les serveurs les
autorisent). Si, par contre, un client possédant un HighID veut télécharger une source d’un client
Page 25
LowID, il va demander à ce dernier d’établir une connexion vers lui par l’intermédiaire du serveur. Le
serveur fera office de relai, et le LowID va alors se connecter au HighID et une communication pourra
alors être effectuée.
Pour observer ce mécanisme nous avons utilisé 3 machines, 192.168.1.4 représente le
HighID, 192.168.1.2 le LowID et 192.168.1.13 représente le serveur. Les deux clients sont connectés
au serveur et le HighID veut télécharger un fichier chez le LowID. La capture sous Wireshark nous
fournit ceci :
Frame 47 : Le HighID envoie un message de type CLIENT CALLBACK REQUEST au serveur pour lui
demandé au LowID d’établir une connexion vers lui. Le message contient le LowID du client. Ici 2.
Frame 60 : Le serveur fait suivre cette demande. Il envoie un message de type SERVER CALLBACK
REQUEST au LowID. Ce message contient l’adresse IP et le port du HighID. Le client va alors pouvoir
établir une connexion vers le HighID.
Frame 63 - 65 : le LowID instancie une connexion vers le HighID. Suit ensuite les messages
traditionnels de connexion. Le HighID pourra alors demander de télécharger un des fichiers du LowID.
Page 26
2. Téléchargement d’un fichier entre deux clients
•
Requête de téléchargement et échange du fichier
Nous allons étudier ici comme se passe l’échange d’un fichier entre deux clients. Pour que
cette procédure se déroule bien selon le protocole eDonkey original, nous avons choisi de mettre en
relation un client eMule 0.49b avec un client Shareaza 2.4.00 (deux clients eMule utiliseraient les
extensions protocolaires propres à eMule). Le client Shareaza est connecté à notre serveur et partage
un fichier. Le client eMule se connecte à son tour au serveur, recherche ce fichier et obtient donc une
source auprès du serveur. C’est un scénario où « tout se passe bien » donc. Le client eMule se
connecte au client Shareaza pour télécharger le fichier. Rappelons comment se déroule cette relation
selon le document « The eMule Protocol Specification » :
Le client A établit une connexion TCP vers le client B et lui envoie un message HELLO et
obtient en retour une réponse HELLO ANSWER.
Le client A demande alors le fichier au client B en envoyant un message FILE REQUEST et un autre
contenant uniquement l’identifiant unique du fichier, ce à quoi le client B réponds par les messages
FILE REQUEST ANSWER et FILE STATUS.
Dans le cas où le fichier est découpé en plusieurs parties de 9.28 Mo (c’est-à-dire que le fichier a une
taille supérieure à 9.28), il y a également échange de la liste des hash des différentes parties
(messages de type HASHSET REQUEST et HASHSET ANSWER) :
Page 27
Le client A envoie ensuite un message START UPLOAD REQUEST et reçoit de la part de B un message
ACCEPT UPLOAD REQUEST. Le client A demande ensuite des parties du fichier avec un message
REQUEST FILE PARTS, auquel B réponds en envoyant des messages SENDING FILE PART.
Nous allons maintenant confronter ce schéma avec ce que nous avons pu observer avec Wireshark.
Dans cette capture, l’adresse IP du client qui veut télécharger le fichier (eMule) est 192.168.1.4 tandis
que celle du client qui détient le fichier (Sharezaza) est 192.168.1.5.
Page 28
Comme attendu, le client eMule commence par établir une connexion TCP vers le client Shareaza :
Après l’établissement de la connexion, le client eMule envoie un message HELLO et reçoit en réponse
un message HELLO ANSWER :
Le client eMule continue ensuite en questionnant le client Shareaza avec un message FILE
REQUEST, et reçoit une réponse FILE REQUEST ANSWER. Puis le client souhaite connaître l’état du
fichier chez le client Shareaza : il envoie donc un message FILE STATUS REQUEST et reçoit comme
réponse un message FILE STATUS. Notons qu’à ce moment eMule envoie également un message
SOURCES REQUEST faisant partie de l’extension du protocole. Il cherche ainsi à obtenir plus de
sources auprès du client Shareaza. Ce dernier ne répond pas, mais la présence de ce message semble
indiquer que Shareaza est en mesure de le comprendre. L’absence de réponse est peut-être due au
fait que le client Shareaza est la seule source pour ce fichier : il ne connaît donc pas d’autres sources
que lui-même. Ce point reste néanmoins à vérifier, mais ce n’est pas notre propos car nous cherchons
à étudier le protocole eDonkey original (ID du protocole : 0xe3).
Le client eMule demande ensuite par un message HASHSET REQUEST la liste complète des
hash de toutes les parties de 9.28 Mo du fichier qu’il souhaite télécharger. Il obtient en réponse un
message HASHSET ANSWER. Ces deux messages sont présents car le fichier en question ici a une
taille supérieure à 9.28 Mo : il est donc constitué de plusieurs parties. Pour un fichier de taille
inférieure à 9.28 Mo, ces deux messages ne sont pas échangés, car dans ce cas le seul identifiant
unique du fichier est suffisant puisqu’il n’y a qu’une seule partie.
Page 29
Le client eMule demande ensuite explicitement le début du téléchargement du fichier par un
message START UPLOAD REQUEST, ce à quoi il obtient une réponse ACCEPT UPLOAD REQUEST de la
part du client Shareaza. Remarquer que Wireshark nomme ces messages SLOT REQUEST et SLOT
GIVEN :
Le client eMule envoie ensuite une requête pour télécharger des parties du fichier avec un
message REQUEST FILE PART. Le client Shareaza y répond ensuite en envoyant les données du fichier
dans des messages de type SENDING FILE PART :
Nous allons nous intéresser de plus près à la structure du message REQUEST FILE PARTS. Voici
le contenu de celui contenu dans le paquet n°42 de la capture ci-dessus :
Premier bloc de
180 Ko
Dans un tel message, le client demande jusqu’à trois blocs maximum du fichier à télécharger.
Les blocs demandés sont déterminés par leurs positions de début (Start Offset) et de fin (End Offset)
par rapport au début du fichier. Nous remarquons ici que les blocs ont une taille fixe de 180 Ko (par
exemple pour le premier bloc : (9912320 – 9728000)/1024 = 184320/1024 = 180). Une fois que ces
trois blocs seront complétés, le client enverra un nouveau message REQUEST FILE PARTS pour
télécharger d’autres blocs et ainsi de suite.
Dans la pratique, le transfert d’un bloc de 180 Ko est effectué par l’envoi de plusieurs messages
SENDING FILE PART qui contiennent chacun une petite partie de ces 180 Ko. Voici un exemple :
Page 30
Comme on le voit ci-dessus, un message SENDING FILE PART (e3 – 0x46) contient les positions
de début et de fin des données qu’il transporte par rapport au début du fichier. Ceci permet de savoir
à quel bloc il appartient (ici en l’occurrence ces données sont contenues au début du premier bloc
dont nous parlons ci-dessus).
Le client Shareaza était configuré pour envoyer exactement 10 Ko de données dans chacun de
ces messages (d’où Trailing/Undecoded data : 10240 bytes). Le réglage avancé de Shareaza pour cela
était eDonkey.FrameSize = 10 KB. Pour compléter un bloc de 180 Ko, le client eMule doit donc
attendre de recevoir 18 messages SENDING FILE PART de 10 Ko. Ces messages sont envoyés dans
l’ordre des données du fichier. Notons enfin qu’avec le protocole eDonkey, les données envoyées ne
sont pas compressées contrairement au protocole étendu d’eMule.
Erratum : Nous écrivions dans la partie II. B. 7. du rapport intermédiaire que l’en-tête du
message SENDING FILE PART contenait la taille du dernier paquet de données (dans le cas où tous les
paquets de données font la même taille sauf la taille du dernier qui est un reste dans une division
entière). Ceci n’est aucunement le cas ici ; c’est peut-être le cas dans la version étendue du protocole
par eMule (qui envoie des données compressées).
Nous nous rendons ici compte que le découpage d’un fichier en parties de 9.28 Mo est un
découpage logique opéré par le protocole eDonkey dans le but de favoriser la diffusion rapide des
fichiers et de permettre de minimiser les conséquences de la présence éventuelle d’erreurs. Ainsi,
lorsqu’un client télécharge une partie de 9.28 Mo, il envoie en fait successivement de nombreux
messages REQUEST FILE PART pour obtenir les blocs de 180 Ko qui recouvrent la partie en question.
Et lorsqu’il récupère un bloc, le client qui détient le fichier lui envoie successivement de nombreux
messages SENDING FILE PART qui recouvrent le bloc en question.
Page 31
Le client A commence le téléchargement
d’une partie de 9.28 Mo du fichier.
Cela se traduit par de nombreux
messages REQUEST FILE PARTS portant
sur des blocs de 180 Ko qui sont envoyés
dans de nombreux messages SENDING
FILE PART.
Le téléchargement de la partie de 9.28
Mo est enfin terminé. Le client pourra
recommencer avec une autre partie.
Une question intéressante à étudier ici est la suivante : si la récupération d’un bloc de 180 Ko
est interrompue avant son terme, est-il possible de reprendre sa récupération à la position où le
téléchargement s’est arrêté ? Le cas échéant, cela doit-il se faire chez le même client ou bien la
reprise peut-elle se faire chez un autre client ?
Pour répondre à ces questions, nous avons lancé le téléchargement d’un fichier par le client
eMule chez le client Shareaza et nous l’avons interrompu immédiatement. Nous avons ensuite fermé
les deux logiciels et installé Shareaza sur un autre poste afin d’avoir un autre client partageant le
même fichier. Nous avons ensuite relancé le téléchargement dans le client eMule et observé les
messages qu’il a envoyés au nouveau client Shareaza.
Page 32
Au début du téléchargement du fichier (chez le premier client Shareaza), le premier message
REQUEST FILE PARTS était le suivant :
Le téléchargement du premier bloc n’a pas été mené à son terme lorsque nous avons
interrompu le téléchargement. Le dernier message SENDING FILE PART pris en compte par eMule
était le suivant (il s’agissait du 3ème message de ce type car eMule indiquait « 30 Ko complété »,
même si nous avons vu passer 6 messages de ce type sur la capture Wireshark) :
Lorsque nous avons relancé le téléchargement avec le second client Shareaza, le premier
message REQUEST FILE PARTS envoyé par eMule était le suivant :
Nous observons alors que le premier bloc demandé est le même que lors de la première
tentative, à la différence que sa position de début (9758720) a été « avancée » à la position de fin
(9758720) du dernier message SENDING FILE PART qui avait été pris en compte. Le téléchargement
reprend donc exactement là où il a été interrompu. Remarquons que la position de fin de ce premier
bloc est toujours la même, ce qui signifie que le découpage des parties de 9.28 Mo du fichier en blocs
de 180 Ko est déterminée de façon définitive.
Page 33
Nous en concluons donc que le téléchargement d’un bloc peut donc tout à fait être
interrompu et repris chez un autre client, grâce au fait que les messages SENDING FILE PART
contiennent les positions de début et de fin des données qu’ils transportent.
•
Fin ou pause/annulation du téléchargement :
Sur toutes les captures de trames que nous avons faites avec Wireshark, nous avons toujours
observé la transmission du même message lorsqu’un client terminait, mettait en pause ou annulait le
téléchargement d’un fichier. Il s’agit de celui-ci :
Ce message eDonkey de type 0x56 est nommé CANCEL TRANSFER dans le document « The
eMule Protocol Specification ». Il est dit dans ce document que ce message est envoyé dans le cas où
un client annule un téléchargement, ou bien lorsqu’il atteint le haut d’une file d’attente alors qu’il a
déjà récupéré le fichier chez un autre client. Ce document mentionne l’existence d’un autre message
de type END OF DOWNLOAD (0x49) que nous n’avons jamais observé dans la mesure où nous avons
toujours achevé les téléchargements avec eMule. Pour en revenir au message 0x56, il est à noter que
le nom donné par Wireshark est SLOT RELEASE, ce qui correspond à la libération d’une place de
téléchargement active chez un client (et recouvre donc tous les cas : fin, annulation).
•
Cas ou le fichier demandé n’existe pas
Que se passe-t-il lorsqu’un client se connecte à un autre client pour demander un fichier que
ce dernier ne possède pas ? Selon le document « The eMule Protocol Specification », le scénario
d’échange de messages est le suivant :
Et voici ce que nous avons observé avec Wireshark :
Page 34
Cette capture a été faite avec un client eMule se connectant à un client Shareaza. L’adresse IP
du client eMule est 192.168.1.120 et celle du client Shareaza est 192.168.1.14 ; Nous observons le
client eMule envoyer son message de type FILE REQUEST, ce après quoi le client Shareaza renvoie un
message de type NO SUCH FILE. Nous observons ensuite après un certain temps (environ 40
secondes) la déconnexion TCP initiée par le client eMule.
3. Gestion des files d’attente
•
Mise en file d’attente/Reprise de téléchargement
Lorsqu’un client partage un fichier sur le réseau, il arrive que de nombreux clients veuillent le
télécharger en même temps. Le client sollicité ne peut alors pas répondre favorablement à toutes les
requêtes et place donc les demandes en trop dans une file d’attente.
Nous étudions ci-dessous le scénario suivant : un client Shareaza partage un fichier qui est
déjà en train d’être téléchargé par un client eMule. Nous avons fait en sorte que Shareaza ne puisse
accepter qu’une connexion à la fois (un seul « slot » de téléchargement) en donnant la valeur 100 %
au paramètre Uploads.FreeBandwithFactor (il faut 100 % de la bande passante maximale disponible
pour pouvoir ouvrir un nouveau slot, ainsi un seul slot maximum peut être ouvert). Un second client
eMule demande ensuite ce fichier et est donc mis en file d’attente. Le premier client eMule
interrompt son téléchargement, ce qui a pour effet de libérer le slot. Le second client eMule atteint
alors le haut de la file d’attente.
N.B. : Nous n’avons pas étudié le cas où le second client eMule aurait téléchargé le fichier entre
temps chez une autre source avant d’atteindre le haut de la file.
Selon le document « The eMule Protocol Specification », voici ce qu’il se passe :
Le client A est mis en file d’attente :
Page 35
Le client A atteint le haut de la file d’attente :
Voici ce que nous avons pu observer avec Wireshark (l’adresse IP du client eMule est
192.168.1.4 et celle du client Shareaza est 192.168.1.2) :
Et lorsque l’autre client eMule libère le slot unique qu’il occupait :
Au début, le client eMule se connecte au client Shareaza et les deux clients s’échangent les
différents messages que nous avons vus précédemment. Lorsque le client eMule envoie le message
START UPLOAD REQUEST (ou SLOT REQUEST sur la capture), il n’obtient pas de réponse ACCEPT
UPLOAD REQUEST (ou SLOT GIVEN) mais il reçoit un message de type QUEUE RANKING. C’est un
message spécifique au protocole étendu d’eMule contenant la position du client dans la file d’attente.
Voici son contenu dans notre scénarion (le client eMule obtient le numéro 1 dans la file d’attente) :
Nous n’observons pas ensuite de déconnexion TCP immédiate entre les deux clients (mais elle
a en fait bien lieue au bout d’un certain temps). Par conséquent, nous n’avons pas observé par la
suite de reconnexion TCP ni de poignée de main (HELLO / HELLO ANSWER) entre les deux clients ().
Ainsi, lorsque l’autre client eMule qui occupait le seul slot disponible se retire, le client
Shareaza envoie directement à notre client eMule un message de type ACCEPT UPLOAD REQUEST (ou
Page 36
SLOT GIVEN) lui permettant de commencer à télécharger le fichier (message de type REQUEST FILE
PARTS, etc).
•
Combien de files d’attente
Nous cherchons à savoir comment un client gère les demandes de connexions des autres
clients et plus particulièrement s’il existe une file d’attente pour chaque fichier partagé, ou bien une
seule file d’attente globale pour l’ensemble des fichiers partagés.
Pour cela, nous avons connecté au serveur un client Shareaza partageant deux fichiers
différents. Nous avons fait en sorte que Shareaza ne puisse accepter qu’une connexion à la fois (un
seul « slot » de téléchargement) en donnant la valeur 100 % au paramètre
Uploads.FreeBandwithFactor (il faut 100 % de la bande passante maximale disponible pour pouvoir
ouvrir un nouveau slot, ainsi un seul slot maximum peut être ouvert).
Un client eMule se connecte alors pour télécharger le fichier 1 et obtient le slot : il télécharge le
fichier. Un deuxième client eMule se connecte à son tour pour télécharger le fichier 1 : il obtient en
réponse un numéro de file d’attente égal à 1. Un troisième client eMule se connecte enfin pour
télécharger cette fois-ci le fichier 2 : il obtient en réponse un numéro de file d’attente égal à 2.
(2) QR =
1
(1) Un
client
obtient le
slot unique
(3) QR =
2
S’il y avait une file d’attente différente pour chaque fichier, le troisième client aurait du être
mis en attente pour ce fichier avec un numéro de file d’attente égal à 1 (puisqu’aucun autre client n’a
réclamé ce fichier avant lui). Pourtant il obtient le numéro 2. Nous pensons donc qu’il n’y aurait
qu’une seule file d’attente pour accéder à l’ensemble des fichiers partagés, en tout cas en ce qui
concerne Shareaza. Il nous faudrait faire des tests plus poussés avec différents clients partageurs pour
pouvoir répondre. Le document « The eMule Protocol Specification » indique par exemple au
contraire qu’il y a une file d’attente pour chaque fichier partagé : eMule gère donc peut être quant à
lui plusieurs files d’attentes. Cela reste à vérifier. Il est ainsi possible que le nombre de files d’attentes
diffère selon les clients eDonkey utilisés.
Page 37
Conclusion
Ce projet nous a passionné, en effet il comportait tous les ingrédients pour susciter notre
curiosité et notre intérêt. Nous nous sommes posés beaucoup de questions autour du protocole
edonkey et nous avons essayé au mieux de les résoudre expérimentalement, découvrir par nousmêmes comment les échanges s’effectuaient entre les divers clients et serveurs. Nous avons pu grâce
à ce projet étudier minutieusement un protocole de communication, cela nous servira
obligatoirement dans notre avenir professionnel. Nous n’avons pas pu étudier l’ensemble du
protocole edonkey parfois par manque de ressources mais aussi par le temps imparti. Nous n’avons
pas étudié la priorité des serveurs (gérée par Shareaza) ni la manière dont sont gérés les nouveaux
serveurs envoyés par un serveur lorsqu’on se connecte à celui-ci. Nous aurions pu aussi étudié les
échanges entre communication entre les serveurs. D’autres questions intéressantes avaient été
soulevées avec les deux doctorants qui n’ont pas été traités Nous avons préféré nous concentrer sur
les parties les plus importantes du protocole edonkey et nous pensons que cet objectif est réussi.
Page 38
SR04 – Réseaux informatiques
COMPTE RENDU
03/12/2008
17H15
CENTRE DE RECHERCHE ROYALLIEU
REUNION ORGANISEE PAR
Equipe projet SR04
TYPE DE REUNION
Réunion de présentation du projet « Implémentation d’une infrastructure eDonkey »
ANIMATEURS
Mahdi Amine ABDELOUAHAB et Sinan HATAHET
PARTICIPANTS
Cédric Aubert
Lahoucine Jazza
Mathieu Max
Mahdi Amine ABDELOUAHAB
Sinan HATAHET
ORDRE DU JOUR
Présentation de notre projet et discussion des pistes de réflexion
envisageables.
TEMPS DE LA REUNION
01H00
DISCUSSION
Les discussions que nous avons tenues avec les deux doctorants étaient principalement axées sur le(s)
mécanisme(s) du protocole eDonkey et nous sommes arrivés au fait que peu de références bibliographiques
existent principalement « The Emule Protocol Specification » écrit par Yorm Kulbak et Danny Bickson de « The
Hebrew University of Jerusalem ».
Nous citerons une liste de pistes de réflexion non exhaustive :
1. Est-ce qu’un client peut télécharger deux fichiers en parallèle de chez le même client ?
2. Est-ce que les clients tiennent une file d’attente par fichier ou une liste d’attente globale pour l’ensemble de
fichiers partagés ?
3. Si le client reçoit une liste de serveurs, comment agit-il c.à.d. les ajoute t-il à la fin d fichier server.met ou les gère
autrement ?
4. Pdonkey API écrite en Perl destinée à manipuler le protocole eDonkey.
5. Ranking binaire : les crédits sont gérés de façon binaire entre chaque deux clients.
6. Le serveur le plus populaire en l’occurrence Lugdunum est open source, néanmoins difficilement trouvable sur
internet !
CONCLUSIONS
Il a été convenu d’inviter les deux doctorants (i.e.: Mahdi Amine ABDELOUAHAB et Sinan HATAHET) à notre présentation
en amphithéâtre et de les informer des résultats auxquels l’on est arrivé à la fin de notre étude.
MESURES A PRENDRE
PERSONNE RESPONSABLE
Page 39
DELAI A RESPECTER
COMMUNICATION ENTRE LA
A MACHINE HOTE ET UNE
UN MACHINE « VIRTUALISEE » SUR VIRTUALBOX
« VirtualBox est une machine virtuelle créée par InnoTek sur les hôtes Windows,
Windows GNU/Linux
32 et 64 bits et Mac OS X supportant Windows (dont Vista), Linux 2.x, OS/2 Warp, OpenBSD et
FreeBSD commee systèmes invité. Après plusieurs années de développement, VirtualBox a été publié
sous la licence GNU GPL en janvier 2007.»
2007 (source Wikipédia).
Après avoir virtualisé notre système d’exploitation (GNU/Linux Ubuntu dans notre cas),
cas au
moins une interface réseau est installée
installé par défaut (on peut le vérifier avec la commande ifconfig
ifc
ou
/sbin/ifconfig ).. Au plus quatre interfaces réseaux peuvent être définies (nommées Adaptateur 1,
Adaptatur 2 , Adaptatur 3, Adaptatur 4) cf. la photo ci-dessous.
Par défaut la machine hôte et la machine virtuelle ne communiquent pas (le Ping entre
e
les
deux machines n’aboutit pas), or dans notre projet nous avons voulu travailler sur la machine
virtuelle comme serveur eDonkey et donc il fallait que cette machine soit accessible aux les autres
clients eDonkey.
Afin de répondre à cette contrainte,
contrainte VirtualBox a prévu une solution quii se résume à ceci :
Dans le menu Machine : Préférences > Réseau :
Page 40
1) Cocher la case « Activer l’adaptateur réseau » s’il n’est pas déjà coché.
2) Dans l’option Attaché à, choisir « adaptateur réseau hôte » et vérifier que la case « Câble
relié » est cochée.
A ce stade, nous avons relié la machine virtuelle à notre réseau.
3) Maintenant on va créer un réseau entre votre ordinateur virtuel et votre ordinateur réel, il
suffit d’appuyer sur le bouton :
puis une boite de dialogue s’ouvre dans laquelle l’on va
choisir le nom de l’interface (exemple : VirtualBox Interface hôte 1).
Maintenant il faut définir sur la machine hôte un pont entre l’interface crée précédemment
et l’interface de connexion par défaut sur la machine hôte (dans la cas exemple c’est la Connexion
réseau sans fil).
Sous Microsoft Windows Vista, aller dans Panneau de configuration > Centre Réseau et
partage > (dans le panneau gauche) Gérer les connexions réseau. Ici, il suffit de sélectionner les deux
interfaces comme dans l’image ci-dessous puis clique droit « Connexions de pont ». C’est le même
principe sous Windows XP.
Enfin, il suffit le redémarrer la machine hôte pour que nos deux machines puissent
communiquer.
Pour vérifier que nos deux machines communiquent, il suffit le taper sur la ligne de
commande: ping @IP( la machine émulée).
Page 41

Implémentation d`une infrastructure P2P eDonkey

Transcription

Documents pareils

Table des matières

Interdire Emule sur un poste

Copyright © www.efarm-project.net Protocole documentation

Les différentes solutions techniques de diffusion

configuration d`emule pour optimiser les

Les Choristes - FACE Foundation

Flyer portes ouvertes à l`IRTESS

Service de restauration scolaire

GYMNASTIQUE RYTHMIQUE DE LA MJC DE BEDOIN

Extractions données tous territoires confondus