Le dépassement de Kazaa par le réseau eDonkey démontre que le partage de fichier est loin d'être mort. Loin de là, puisqu'il ne cesse de croître malgré les répressions sévissant dans les pays. Loin d'être illégal, le P2P est d'abord une technologie....

Logo

Réseaux

Utilisateurs

eDonkey

5,800,000

FastTrack

2,300,000

Gnutella

1,850,000

Ares/ Warez

1,400,000

Overnet

900,000

iMesh

850,000

BitTorrent

> 570,000

Gnutella 2

570,000

Direct Connect

320,000

MP2P

270,000

OpenNap

266,000

OpenFT

125,000

Filetopia

4,650

eMule Kademlia

N/D

 C'est vers fin 1998 que tout commence, Shawn Fanning, alors étudiant à Boston et âgé de 17 ans réalise un logiciel qui lui permettra d'échanger ses mp3 avec ses amis suite à la demande de son colocataire qui voulait trouver des mp3 de rap gratuits. Ce futur programme reposait sur le constat suivant: les recherches de mp3 dans les moteurs de recherches étaient quasi inutiles (mp3.com à l'époque hébergeait les mp3 que les utilisateurs uploadaient) tant les réponses étaient inappropriées. Shawn, dont son pseudo favori était Napster, choisi celui-ci pour son application qui deviendra sans doute le pseudo le plus connu au monde!  Il envoie alors la première version sur download.com et devient très rapidement l'un des hits de ce dernier. Ce Napster est constitué: d’un navigateur Web, d’un serveur de fichiers, d’un module de messagerie instantanée et d’un lecteur de fichiers mp3. Le serveur permet de mettre à jour en permanence la liste des fichiers audio partagés par les utilisateurs connectés à ce réseau.

 Ce fonctionnement d'échange, dont le principe est le Peer to Peer, rappelle l'origine fondamentale du net: L'échange direct d'informations entre universités. C'est pendant l'été 1999 que la première bêta devient disponible au grand public.

 En fin 2000, Napster compte 25 Millions d'usagers et est dans les 25 sites américains les plus consultés.

 Le 12 Mars 2001, Napster est obligé d'instaurer un système de filtrage, ensuite la décadence arrive, avec des rachats et des protections à tout va.

 Le 29 Octobre 2003, le nouveau Napster est sorti. Mais loin de son concept original, puisque c'est la société Roxio qui a édité Napster 2.0, vendant le titre à 99 cents (de dollars).

 Le logiciel se base sur leur pile de protocole P2P nommé FastTrack, un algorithme de communication propriétaire.

 KaZaA permet à Morpheus et Grokster d’utiliser la technologie FastTrack.

 En Octobre 2001, la MPAA et la RIAA traîne KaZaA, Morpheus et Grokster en justice

 En Novembre 2001, Consumer Empowerment est aussi traîné en justice. La cour oblige KaZaA à éliminer tout contenu illégal de son réseau.

 En Janvier 2002, Zennstrom et Friis vendent KaZaA et son site web à Sharman Networks, basé à Vanuatu, une île dans le Pacifique.

 En Février. 2002, les utilisateurs de Morpheus ne peuvent plus accéder au réseau FastTrack et se contentent de rejoindre le réseau Gnutella.

 En Avril 2002, Sharman Networks accepte d’inclure AltNet,  une application P2P développée par Brilliant Digital, dans KaZaA.
                                          

 Tout d'abord le client se connecte au serveur central (et oui Kazaa est centralisé!!! ) dont il connaît l'adresse. Ce serveur central donne au client une liste des "Supernodes" (Supernoeuds): ce sont des clients puissants et rapides qui connaissent un certain nombre d'autres clients. Donc le client est redirigé vers ces Supernoeuds (qui se connaissent entre eux) avec qui il correspond, c'est par eux que passent les recherches à travers TOUT le réseau. De plus, pour être sûrs de pouvoir fonctionner en cas d'arrêt de FastTrack, les développeurs de Kazaa et de Morpheus se sont arrangés pour qu'un client devienne Super-super-noeud, c'est à dire qu'un client puissant devient base de donnée de TOUS les super-noeuds.

Note: les logiciels tiers (MLDonkey) se connectant au réseau FastTrack ne se connectent pas au serveur central, ils se connectent directement aux super-noeuds.

 Et c'est utilisateurs n'étaient pas des anges, ils décompilent et publient sur le net le code source. Du coup, des équipes de développement se forment et des nouveaux programmes voient le jour: Morpheus, LimeWire, Gnucleus et d'autres, tous basés sur le protocole GNUtella

 La version mise en ligne par l'équipe de Nullsoft n'était alors qu'une version bêta et était destinée à subir des améliorations et être optimisée. Mais le destin redirige sa course et la version 0.4 du projet GNUtella se dévoile sur Internet (cette version est encore utilisée par certains logiciels)

 Le but des développeurs du projet GNUtella était de placer le protocole, le logiciel sous Licence Libre (GPL, d'où le GNU de GNUtella) et le code source libre d'accès (Open Source), pour qu'il évolue de lui même (les utilisateurs ajoutent leur grain de sel pour l'améliorer). Mais à cause d'America Online (AOL) qui les en empêche, seules des versions décompilées du code source sont divulguées. Histoire que GNUtella n'évolue pas n'importe comment, un site officiel est crée pour accueillir toutes les idées et pour poster les codes sources modifiés, l'adresse était: Gnutella.wego.com

 Gene Kan fut placé à la tête du consortium GNUtella dut à ses efforts dans les premières semaines de parution de GNUtella pour que celui-ci reste considéré comme un protocole d'avenir.  Son investissement initial fut le plan de 7 jours, pendant lesquels il répara les premières failles du réseau. C'est aussi lui crée le site central ayant rapport avec Gnutella: Gnutella.wego.com. Grâce à ses efforts et à ceux de tant d'autres, GNUtella est maintenant considéré comme un protocole de partage de fichiers.

Gene Kan s'est suicidé le 29 Juin 2002, à l'âge de 25 ans, lauréat 

"L'esprit de Gene et ses talents étaient fins et toujours au service de l'Humanité et dans de grands dessins, et il est vraiment ironique qu'il accèlera la transmission de l'information mais que l'annonce de sa mort mit tant de temps à voyager".
                                         

 Aujourd'hui, GNUtella est doté de centaines de clones: Gnucleus, Xolox, Bearshare ou de logiciels multi-réseaux: Morpheus,  Shareaza, mlDonkey et bien d'autres...

 Un ordinateur A qui veut se connecter au réseau, doit d'abord trouver un utilisateur du réseau: B, parce que c'est un réseau décentralisé, il n'y a pas de serveur qui puisse adresser un chemin à A. Pour trouver ce B, le logiciel se connecte à une base de donnée sur Internet dans laquelle les adresses de quelques utilisateurs sont enregistrées, ce sont les GWebCaches. Une fois un autre client trouvé, ce dernier donne une liste d'autres clients à A: il les ping. Une fois en relation avec les relations de B, la chaîne continue. Les relations de B renvoient alors un message à A..... après un certain temps.

 Maintenant vous êtes prêt à effectuer la recherche, vous envoyez un message à B qui regarde dans sa liste de fichiers, s'il le trouve, il vous renvoie un message, le PONG, s'il ne le trouve pas, in ne fait rien. B transmet de toute façon le message à ses liaisons qui recherchent dans leurs fichiers et appellent à leur tour leurs propres liaisons. Encore une fois cela prend du temps et en plus vous ne savez pas si la recherche est terminée ou pas, car le réseau utilise le système TTL (Time To Live ou Temps à Vivre), c'est-à-dire que pour ne pas que le réseau soit overbooké par des recherches infinies, la recherche est limitée en propagation et se contente généralement de parcourir 7 niveaux de la pyramide des connexions.
Ainsi, en théorie, seulement x personnes devraient être interrogées, car je répète, en théorie chaque client connaît 3 autres clients:

 Une fois que votre ordinateur a reçu un message annonçant que la recherche était fructueuse, il contact alors l'hôte sous forme de requête http, le même protocole utilisé pour le World Wide Web. C'est ici l'avantage définitif du réseau et du protocole Gnutella, le trafic du réseau peut-être considéré comme un trafic web, donc invisible en tant que partage de fichier, mais reste lent et et utilise pas mal de bande passante (bandwith) avec des recherches peu fructueuses.
 NOTE: Pour résoudre ce problème du faible nombre clients "scannés" Gnutella introduit maintenant des super-noeuds, comme Kazaa. Ces mini serveurs peuvent connaître jusqu'à 1500 clients chacun, ce qui étend la recherche phénoménalement (oui, j'aime bien ce néologisme). En fait il suffirait de 100 serveurs pour interconnecter 150,000 personnes, ce qui est vraiment ridicule comme nombre: seulement 1000 serveurs permettraient de connecter 1,500,000, le seul problème persistant serait le problème de bande passante chez les serveurs, mais avec une connexion américaine cela ne poserait aucun problème (une connexion belge le ferait aussi ;-) ).
En fait, au lieu que chaque personne connaisse 3 clients, chaque personne connaît une personne qui en connaît 200, 300 voir 1500. Les super-noeuds s'inter-connectant, la recherche devient vraiment fructueuse.

 Depuis le 28 Mai 2004, Shareaza est passé en Open Source, le développement en est ainsi dynamisé et les codes des différents réseaux sont dévoilés, permettant à ces mêmes réseaux de nouvelles intégrations dans des logiciels: le boost du P2P.

 Gnutella 2 est le digne fils de Gnutella premier du nom. Il a repris tous les bons éléments (réseau décentralisé, capacité) et a comblé tous les failles du réseau (occupation bande passante, recherches peu fructueuses). Pour ce faire, Shareaza se connecte à un cache (fichier avec des adresses) de serveurs. Il essaie alors de se connecter à ces serveurs. Mais ce ne sont pas des serveurs fixes, en fait ce sont des super clients, qu'on appelle des super-nœuds (1 nœud est 1 hub = 1 petit serveur). Pour devenir un nœud, il faut être connecté depuis au moins 2 heures au réseau et avoir une bonne bande passante. Cette feuille (ce client = utilisateur) devenue nœud, le nœud apprend les adresses d'environs 400 clients autour de lui. Lui même connaît 6 autres nœuds.
 Quand on commence une recherche, la recherche (= le ping) part vers les autres nœuds qui demandes à leurs feuilles si ils ont des réponses à la recherche posée. Lorsqu'un utilisateur a le fichier demandé, il envoie un message (= le pong) à son nœud qui le renvoie au nœud connecté à l'utilisateur. Lorsqu'un noeud a interrogé les feuilles autour de lui et qu'il n'a trouvé aucune réponses, il ne renvoie aucun message au client. Cette recherche parcourt aussi tous les nœuds connectés à ce même noeud. Je m'explique, le premier nœud, auquel l'utilisateur est connecté, connaît 6 nœuds (qui connaissent chacun 300 personnes), puis ces 6 nœuds connaissent chacun 6 noeuds (qui connaissent chacun 300 personnes) et ainsi de suite sur plusieurs niveaux.

 Le soir du 13 Mai 2002, Merkur décide décide de développer son propre client pour le réseau eDonkey tellement il trouve le client officiel inadapté. Il rassemble alors une petite équipe de développeurs et la tâche commence. Leur but étant de rester dans le chemin d'eDonkey tout en ajoutant des tonnes d'options et d'utilitaires, et surtout, au summum de la nouveauté: une interface agréable et simple! A cette époque, l'équipe n'aurait jamais imaginé le succès rencontré par son soft.
 Aujourd'hui eMule est utilisé par 95 % des gens sur le réseau et de plus s'est doté de son propre réseau: Kademlia.

 eDonkey n'est en fait dans qu'une sorte de Neo-Napster. Il utilise des serveurs centraux auxquels se connectent tous les clients. Les serveurs par contre sont inter-connectés.
 Il faut savoir qu'eDonkey a introduit le système de quota d'upload, j'envoie à 5 ko/s, j'ai le droit de recevoir 4 fois plus (c'est à dire 20 ko/s, trop fort ;-) ). A partir de 10 ko/s la vitesse de téléchargement est illimitée.
 Bon alors, on recommence depuis le début: un client se connecte à une liste de serveurs qu'il a préalablement téléchargé (ce sont les fichiers .met), une fois connecté au serveur, il lui transmet sa liste de fichiers partagés en utilisant le port 4661. Jusque là pas de quoi s'extasier vous me direz, c'est un Napster un chtit peu ameilloré! Et c'est là qu'intervient le protocole MFTP.
 Sur un système classique de partage de fichiers, ne sont disponibles que les sources possédant le fichier complet - le défaut, c'est que pour télécharger des gros fichiers c'est vraiment pas le pied. Grâce au MFTP, qui utilise le protocole de transfert UDP, (Multisource File Transfert Protocol qui en français peut se traduire par Protocole de Transfert de Fichiers Multisources) un client A peut télécharger un fichier à partir d'un autre qui en a toutes les parties (client B)et d'un qui n'en possède que quelques bouts (client C). Bien sûr, celui possédant tous les bouts, donc le client B, privilégiera le transferts de morceaux que le client C ne possède pas. L'avantage? Des petits bouts sont répartis et comme çà il est plus facile de récupérer le fichier intégral, au lieu que tout le monde fasse la queue pour le même morceau. De plus, d'autres clients pourront toujours récupérer le petit peu téléchargé par le client A. Encore mieux, eDonkey/eMule gère les files d'attente en donnant une plus forte priorité à ceux qui possèdent une très grosse partie du fichier, ce qui fait que plus de sources possèderont TOUS les morceaux.
 Portrait du plus gros serveur eDonkey:
 - Bi-processeur AMD Opteron 248
 - 2 x 2 Go de DDR PC 3200
 - Connexion 10 Mo/s
 - Coût 3500 € dont 1500 € de connexion /an

 L'ID expliquée: Vous avez sans doute déjà eu un problème de LowID, surtout si vous utilisez eDonkey/eMule depuis un petit temps. Il faut savoir que l'ID est unique pour chaque personne, celui-ci est calculé à la connexion du client sur le serveur, comme le hash (lien e2k) est unique pour chaque fichier.
 Comment l'ID est attribué?
Lors de la connexion du client sur le serveur, ce dernier essaye de contacter le client sur le port TCP 4662, si cette connexion passe, alors le client aura un HighID.
 Quelle est la différence, quelle est l'importance?
 Un lowID ne peut être contacté, on ne peut connaître son adresse ip. De plus, un LowID n'aura accès qu'à quelques sources lors des téléchargements car beaucoup de HighID ne pourront pas lui répondre. Par contre un LowID aura aussi très peu d'envois.
 L'ID d'un utilisateur possédant un HighID est exactement son adresse ip retranscrite différemment. C'est ce qui permet ces si nombreuses connexions rapides. Un client a un adresse IP A.B.C.D, celle-ci est alors retranscrite en hexadécimal: aa.bb.cc.dd, puis les octets sont inversés, ce qui donne alors ddccbbaa, et alors, dernière étape, on repasse tout en décimal. 
Ex: Mon IP est 

C'est ce qui explique que si vous changez de serveurs lors d'une même session Internet vous gardez le même ID.

Calculez votre ID ici.

 Dans le réseau Kademlia, chaque utilisateur est une sorte de serveur. Pour se connecter au réseau, il faut qu'eMule connaisse au moins 1 client, en fait ça marche comme pour se connecter au réseau Gnutella.

 Dès lors que le client connaît un nœud (A), ce même nœud va envoyer ses données d'identification au client pendant qu'il contactera lui-même les nœuds avec qui il est en contact. Appelons les B et C. Une fois l'appel d'identification reçu, B et C renvoient un message au client à travers A, pendant qu'eux même contactent à leur tour leurs propres nœuds avec qui ils sont en connexion. Ainsi le client se construit un catalogue de connexions. 

 Imaginons que le petit client ait envie d'exécuter une recherche. Celui-ci recherche dans son annuaire les nœuds les plus proches, puis, tout comme sur Gnutella, le nœud renvoie un message à A si des fichiers correspondent aux critères de recherche.

Exemple de connection à un réseau centralisé (connection à un serveur : eMule classique ).

 Tout d'abord, MP2P est un réseau décentralisé PROPRIÉTAIRE. Donc, la première étape de son fonctionnement est inconnue. Décentralisé on connaissait, notamment avec Gnutella. Mais pour accéder à ce dernier, on connaissait une liste de clients (voir Fonctionnement Gnutella), mais les logiciels utilisant le réseau MP2P ne semblent pas avoir besoin de ces prémices. Donc, mystère sur la façon dont ils se connectent au réseau.