Gnutella/fr

From Shareaza Wiki
Jump to navigation Jump to search
  Updated:

This page has been updated on 29 mars 2014 for the release of Shareaza v2.7.x.0.

e
  Contenu stable

Les informations de cette page s'appliquent à toutes les versions de Shareaza tant qu'il n'y a pas de modification majeur.

e

Présentation


Gnutella est un grand réseaux "pair-à-pairs" (P2P), qui au moment de sa création, fut le premier réseau P2P décentralisé. Plus tard, d'autres réseaux adoptèrent ce modèle. En juin 2005, Gnutella reliait 1,81 million d'ordinateur, pour passer au dessus des 3 millions de nœuds en janvier 2006. Dans le courant de l'année 2007, il était le plus populaire des réseaux de partage de fichiers sur internet avec une estimation de plus de 40% de part de marché.
Il célébra ses 10 ans le 14 mars 2010.

Le logo de Gnutella (G1)
Le logo de Gnutella (G1)


Histoire

Le premier client fut développé par Justin Frankel et Tom Pepper développeurs chez Nullsoft au début des années 2000. Le 14 mars 2000, le programme était disponible en téléchargement sur les serveurs de Nullsoft. Cet événement fut prématurément annoncé sur Slashdot(1.), Il y eu des milliers de téléchargements du programme ce jour là. Le code source fut libéré plus tard sous Licence publique générale GNU (GPL).

Le jour suivant, AOL qui venait d'acquérir Nullsoft, stoppa la mise à disposition du programme pour des préoccupations légales(2.). Nullsoft fut contraint de ne pas aller plus loin dans le projet. Cela ne stoppa pas Gnutella, après plusieurs jours, le code du protocole subit une rétro-ingénierie et des clones du logiciels libres et open-source firent leurs apparitions. Ce développement parallèle de différents clients, par différents groupes garde le même Modus operandi à ce jour.

Le réseau Gnutella est une réelle alternative aux système semi-centralisé tel que FastTrack (KaZaA) et à l'original Napster. La popularité initiale du réseau a été stimulée par Napster qui reçut des menaces légales en 2001.Cette montée en croissance de la popularité, a révélé les limites de l'adaptabilité du protocole initial. En 2001, une variation du protocole (première implémentation dans un logiciel propriétaire et aux sources fermées permis une amélioration d'adaptabilité. Au lieu de traiter tous les nœuds comme client et serveur, quelques nœuds ont été traités comme "super nœuds" (Ultrapairs), routant les requêtes de recherche et leur réponses pour les nœuds connectés à eux.

Cela permis au réseau de gagner encore plus en popularité. Fin 2001, le client Gnutella Limewire (Basic) sorti, gratuit et open source. En février 2002,la société éditrice de Morpheus, abandonne FastTrack et sorti un nouveau client basé sur un client Gnutella qui est libre et open source Gnucleus.

Aujourd'hui, le mot "Gnutella" se réfère pas au projet ou une parti du logiciel, mais au protocole ouvert utilisé par différents clients. Gnutella est un mot-valise formé de GNU et de Nutella (la pâte à tartiner), il est supposé que Frankel et Pepper en étaient gourmand sur le projet original, et destinaient leur programme à la Licence publique générale GNU. Gnutella n'est pas associé au projet GNU(3.) ou à son réseau Pair-à-pair GNUnet.

Conception

La connexion

Pour comprendre comment Gnutella fonctionne, imaginez un large cercle d'utilisateur (appelé Nœuds), qui ont un logiciel client Gnutella quel-qu'il soit.

A la connexion initiale, le logiciel client doit amorcer la connexion à un autre nœud. Pour cela Différentes méthodes sont utilisées:

  • Le client Gnutella possède une liste intégrée d'adresse IP de nœuds (appelé voisin ou hôtes) aux quelles, il est potentiellement capable de se connecter.
  • La mise à jour des web caches de nœuds (appelé Gnutella Web Cache (GWC))
  • Les caches UDP hôte et plus rarement via IRC

Une fois connecté, le client demande une liste fonctionnelle d'adresse. Il tente alors de se connecter aux nœuds de la liste reçue, aussi bien qu'aux nœuds dont il reçoit l'adresse depuis d'autres clients, jusqu'à ce qu'il atteigne un certain quota. Il se connecte toujours à plusieurs nœuds, mettant en caches les adresses de connexion possible qu'il n'a pas essayé et en supprimant les adresses avec qui, il n'a pas pu établir de connexion.

Les recherches

Quand un utilisateur effectue une recherche, le client Gnutella envoi une requête à chacun des nœuds activement connectés.
Dans la version 0.4 du protocole, le nombre de nœuds activement connectés pour un client était vraiment petit (autour de 5 pour 1), ainsi chaque nœud retransmet la requête à chacun des nœuds auxquels il est activement connecté et à leurs tours il retransmettent la requête, ainsi de suite... Ce jusqu'à ce que la requête atteigne un nombre de "bonds" pré-déterminé (maximum 7) par le client qui l'a envoyée .

La version 0.6, Gnutella est un réseau composite formé de nœuds "feuilles" et d'ultra nœuds (appelé UltraPairs (UltraPeers en anglais)). Les feuilles sont connectées à un petit nombre d'UltraPairs (typiquement 3) tandis qu'un UltraPair peut être connecté à plus de 32 autres UltraPairs.

Feuilles et ultrapairs utilise un Protocole de Routage de Requêtes (Query Routing Protocol ou QRP) pour échanger des Tables de Routage de Requêtes (QRT) constituées de mots clés hachés. Une feuille envoi sa QRT à chacun des ultrapairs auquels il est connecté, puis les UltraPairs combinent les QRT reçues de leurs feuilles, plus leurs QRT (s'ils partagent des fichiers) et les échangent avec leurs voisins.

Ainsi un client interrogeant un ultrapeer peut rechercher sur 30 autres clients avec une seule requête. Si la requête est retransmise aux 30 autres ultrapeers auquel il est connecté, sa recherche atteint le contenu de 900 clients... Autre point non négligeable, les clients ne reçoivent plus de requêtes de recherche, on dit qu'ils sont protégés par leur ultrapair. Cela permet en outre aux utilisateurs connectés à Internet en bas débit de pouvoir utiliser Gnutella sans diminuer leurs performances.

Si une recherche retourne des résultats, le nœud qui possède le fichier contacte le nœud initiateur de la recherche. Dans le protocole classique de Gnutella, les messages de réponse suivent le même parcours que que la requête de recherche, car la requête ne contient pas de données permettant d'identifier l'hôte initiateur de la recherche. Ce schéma, fut révisé plus tard... Car maintenant, la requête contient l'adresse IP et le numéro de port de l'hôte, ainsi les résultats de recherches sont directement délivré à l'hôte initiateur de la recherche via l'UDP par l'ultrapair du nœud. Cela permet de diminuer la somme de trafic acheminé par le réseau Gnutella.

Chemin effectué par une requête (en vert) de recherche et sa réponse (en rouge).

Si un utilisateur décide de télécharger un fichier, son client Gnutella et le client dépositaire du fichier négocient un transfert de fichier. Si le nœud qui possède le fichier n'est pas derrière un pare-feu, le deux clients peuvent se connecter directement et procéder à l'échange de fichier. Si par contre le dépositaire (la source) du fichier est derrière un pare-feu, celui-ci ne peut pas recevoir les connexions entrantes. Le client qui recherche le fichier est obligé d'envoyer une "requête poussée" à l'ultrapair pour demander à l'hôte distant d'initier la connexion à sa place.

Auparavant, cette "requête poussée" suivait le parcours inverse qu'avait parcouru la requête. Cela était un parcours incertain, car de nombreux hôtes par lesquels la requêtes était passé se déconnectaient et brisaient la connexion, et les paquets acheminés sont toujours soumis à un contrôle de flux.

Par conséquent ce que l'on appelle des "proxys poussés" a été introduits. Ce sont généralement les ultrapeers d'un nœud feuille et ils sont annoncés dans les résultats de recherche. Le client se connecte à l'un de ces "proxys poussés" à l'aide d'une requête HTTP et le proxy envoie une "demande poussé" à la source du fichier pour le compte du client demandeur. Normalement, il est également possible d'envoyer une requête poussée via l'UDP au proxy poussé ce qui est plus efficace que d'utiliser le protocole TCP.

Les proxys poussés ont deux avantages :

  • Les connexions UltraPairs - feuilles sont plus stables, les parcours que font les requêtes poussées sont beaucoup plus fiable.
  • Il réduit le volume du trafic acheminé par le réseau Gnutella.

Enfin, quand un utilisateur se déconnecte, le logiciel client enregistre la liste des nœuds à qui il était activement connecté et celles recueillies à partir des paquets pong pour les utiliser à sa prochaine tentative de connexion afin de devenir indépendant de toute forme de services d'amorçage.

En pratique, cette méthode de recherche sur le réseau Gnutella est peu fiable. Chaque nœud est l'ordinateur d'un utilisateur et en tant que tel, ils se connectent et se déconnectent constamment, de fait le réseau n'est jamais complétement stable. En outre, le volume de bande passante sur Gnutella pour les requêtes de recherches a connue croissance exponentielle du nombre d'utilisateurs connectés, saturant souvent les connexions et rendant lents les nœuds inutiles.

Par conséquent, les requêtes de recherches sont souvent lâchées et les requêtes restantes n'atteignent qu'un petite partie du réseau. Cette observation identifie le réseau Gnutella comme un système distribué inextensible et à inspiré le développement des "Tables de hachage distribuées" qui sont beaucoup plus extensibles mais qui ne supportent uniquement qu'une correspondance exacte, plutôt que des les mots clés d'une recherche.

Pour résoudre les problèmes de goulots d'étranglement , les développeurs de gnutella ont mis en place un système à plusieurs niveaux d'ultrapairs et de feuilles. Plutôt que tous les nœuds soient considérés comme égaux, les nœuds entrant sur le réseau ont été maintenus "en marge" du réseaux comme feuilles, non responsables de l'acheminement. Les nœuds capables de router les messages furent promus UltraPairs acceptant la connexion des feuilles et routant les requêtes de recherche ainsi que les messages de maintenance du réseau. Cela permet aux requêtes de recherches de se propager davantage à travers le réseau et permis de nombreuses modifications dans la topologie qui ont amélioré grandement l'efficacité et l'extensibilité.

En outre, Gnutella a adopté un certain nombre d'autres techniques pour résoudre la surcharge de trafic et rendre les recherches plus efficaces. Notamment le Protocole de Routage des Requêtes (Query Routing Protocol ou QRP) et les Requêtes Dynamiques (Dynamic Querying ou DQ). Avec QRP, les recherches n'atteignent seulement que clients qui sont susceptible de posséder le fichier recherché. de fait, les recherches de fichiers 'rares' deviennent plus efficaces. Avec DQ les recherches s'arrêtent aussitôt que le programme trouve suffisamment de résultats, ce qui réduit significativement la somme du trafic causé par les recherches "populaires".

Un des avantages que possède Gnutella est sa décentralisation, il serait extrêmement difficile de faire tomber son réseau contrairement à Napster qui avait son réseau entier de connecté à un serveur central qui, en son temps fut facile de faire fermé par les ayants droits. Gnutella ne peut être arrêté par la fermeture de quelques nœuds et il est impossible pour une compagnie de prendre le contrôle du contenu partagé sur le réseau dont seuls les utilisateurs sont dépositaires, qui est également due aux nombreux clients Gnutella libre et open source qui se partagent le réseau.

Caractéristiques et Extensions du Protocole

Comme nous l'avons vu plus haut, le protocole Gnutella a purement fonctionné à base de requêtes d'inondation, dans sa version 0.4, le protocole réseau utilise cinq différents types de paquets :

  • les pings : pour la découverte des hôtes sur le réseau
  • les pongs : qui est la réponse aux ping
  • les requêtes : pour la recherche de fichier
  • les hits de requête : qui est la réponse a la requête
  • poussée (push) : qui est la requête au téléchargement derrière un pare-feu

Ce sont les paquets concernés principalement par la recherche du réseau Gnutella. Les transferts de fichiers sont gérés via le protocole HTTP.

Le développement du protocole Gnutella est actuellement dirigé par les "GDF" (Gnutella Developers Forum). Plusieurs extension du protocole ont été et sont développées par des éditeurs de logiciels et par les développeurs libre du GDF. Ces extensions inclues le routage intelligent des requêtes,la somme de contrôle SHA-1, les hits de requêtes via l'UDP, l'interrogation via UDP , les requêtes dynamiques via le TCP, le transfert de fichier via l'UDP, les métadonnéesXML, l'échange de source et le téléchargement parallèle en tranches ('essaimage').

Il y eu des efforts pour finaliser ces extensions de spécifications du protocole Gnutella 0.6 sur le site de développement. La version 0.4 de Gnutella -bien qu'étant toujours la dernière spécification du protocole- est obsolète, puisque toutes les extensions existent que sous la forme de propositions. Dans les fait, il serait extrêmement difficile voir impossible aujourd'hui de se connecter avec la poignée de main de la version 0.4.

Le protocole Gnutella est toujours en cours de développement et en dépit des tentatives de faire une rupture nette avec la complexité héritée de l'ancienne version gnutella 0.4 et de concevoir une nouvelle architecture. Gnutella est encore l'un des protocoles les plus réussies de partage de fichiers à ce jour.

Logiciels

Les tableaux suivants comparent les informations générales et techniques de plusieurs applications qui supportent le réseau Gnutella.Ils n'ont pas pour vocation de donner une liste complète des clients Gnutella, ils sont limités aux clients qui sont capables de participer actuellement au réseau Gnutella.

Spécifications Générales

Nom Environnement Licence Héritage
Acquisition Mac OS X Propriétaire LimeWire
BearShare
(Avant la Version 6)
Microsoft Windows Propriétaire Travail Original
BearFlix Microsoft Windows Propriétaire BearShare
Cabos Java GNU GPL LimeWire
FilesWire Java Propriétaire Travail Original
FrostWire Java GNU GPL LimeWire
giFT
(plugin Gnutella)
Multi plate-forme GNU GPL Travail Original
Gnucleus Microsoft Windows GNU GPL, GNU LGPL Travail Original
Gtk-gnutella Type Unix, Mac OS X, Microsoft Windows GNU GPL Travail Original
iMesh
(Avant la Version 6)
Microsoft Windows Propriétaire GnucDNA
KCeasy Microsoft Windows GNU GPL giFT
Kiwi Alpha Microsoft Windows GnucDNA
LimeWire Java GNU GPL Travail Original
Morpheus Microsoft Windows Propriétaire GnucDNA
Phex Java GNU GPL Travail Original
Poisoned] Mac OS X GNU GPL giFT
Shareaza Microsoft Windows GNU GPL Travail Original
Symella Symbian OS GNU GPL Travail Original
Zultrax Microsoft Windows Propriétaire Travail Original

Caractéristiques des clients Gnutella

Clients Recherche
à partir
du hache
tChat
[-›]
Liste d'amis Manipulation des
fichiers larges
(> 4 Gio)
Unicode-compatible
Routage requêtes
Mappage des ports UPnP
[-›]
NAT traversal**
[-›]
NAT port mapping RUDP
[-›]
Proxy poussé TCP Proxy poussé UDP Ultrapair GWebCache
[-›]
Cache d'hôte UDP
[-›]
TLS Autres
BearShare
Yes


Yes


Yes


No No Yes


Yes


Yes


Yes


Yes


No Yes


Yes


No Yes


No -
giFT (coeur & plugins) Yes


N/A N/A No No ? ? ? No yes a
[-›]


No Non b
[-›]
Yes


No No No -
GnucDNA c
[-›]
Yes


N/A N/A No No No No No No Yes


No Non b
[-›]
Yes


No No No -
gtk-gnutella yes d
[-›]


No No Yes


Yes


Yes


Yes


Yes


No Yes


Yes


Yes


No (tombé) Yes


Yes


Yes


IPv6, THD
LimeWireh
[-›]
yes d
[-›]


Yes


Gmail ou XMPP


Yes


Yes


Yes


yes e
[-›]


yes g
[-›]


Yes


Yes


Yes


Yes


Yes


Yes


Yes


Yes


THD
Phex Yes


Yes


No Yes


Yes


No yes socks
[-›]


No No Yes


No Yes


Yes


Yes


Yes


Yes


I2P
Shareaza Yes


Yes


Yes


Yes


No Yes


Yes


Yes


No Yes


Yes


Yes


Yes


yes f
[-›]


Yes


No G2, BT, eD2k, IRC

Notes

  •  tChat : Se réfère au tchat client-à-client.
  •  Mappage des ports UPnP : UPnP Configure automatiquement la redirection des ports (Requière un routeur qui supporte l'UPnP)
  •  GWebCache : GWebCache Le cache d'hôtes est la méthode d'Amorçage client (Bootstrapping) privilégiée.
  •  THEX : Tree Hash EXchange format
  •  a : TCP Client seulement
  •  b : Degré sortant non élevé, donc inutilisable sous sa forme actuelle.
  •  c : Version 0.9.2.7
  •  d : Via Kademlia (basé sur le DHT réseau Mojito) seulement supporté par LimeWire et gtk-Gnutella (à partir de la version r15750); complètement différent des recherches SHA-1 supporté par tous les autres clients Gnutella.
  •  e : Port triggering ou firewall à firewall (FW2FW).
  •  socks : Via un proxy SOCKS qui peut faire tunnel sur SSH.
  •  f : Depuis la version 2.2.4.0
  •  g : Automatique avec UPnP, ou en configuration manuelle dans les options "Pare-feu" de LimeWire.
  •  h : Comme le client LimeWire n'est officiellement plus disponible, des client tels que FrostWire qui sont basé sur le code de LimeWire peuvent être utilisés comme alternative.
  • Morpheus Diffère de manière significative et peut-être complètement indépendant du code du moteur GnucDNA. Morpheus peut fonctionner comme un Ultrapair moderne tandis que les autres clients GnucDNA ne le peuvent pas.
  • Gnucleus et Kiwi Alpha utilise le moteur de GnucDNA.
  • BearFlix doit être similaire à BearShare.
  • GiFTcurs, Apollon, FilePipe, GiFToxic, GiFTui, GiFTwin32, KCeasy, Poisoned, et Xfactor sont des Interface Graphique Utilisateur pour le moteur de giFT.
  • Etomi utilise un réseau obsolète de Shareaza.
  • 360Share, LemonWire, MP3Torpedo, and DexterWire sont des paquets de LimeWire.
  • FrostWire est presque identique à LimeWire; Acquisition et Cabos ont une Interface Utilisateur personnalisé mais qui utilise le moteur de LimeWire.

Références

1. Annonce de la sortie de Gnutella sur Slashdot (en anglais)
2. AOL et Gnutella par CNN
3. Quant à Gnutella(www.gnu.org)

Source de cet article : http://en.wikipedia.org/wiki/Gnutella



Navigation:     Page d'accueil > Networks and Hashes/fr > Gnutella/fr