Les news

Les articles

Partenaires

Slyck

Aspects techniques

Les systèmes centralisés sont donc les premiers systèmes pair-à-pair à voir le jour, dès juin 1999 avec Napster. Il fut suivi d'autres protocoles du même type, comme DirectConnect (qui a évolué en DC++). Le système Napster propose le téléchargement de fichiers musicaux, mais il n'est pas encore formellement pair-à-pair, puisqu'il repose sur l'utilisation d'un serveur stable pour la mise en relation des utilisateurs. Le créateur de Napster fut pour cela rapidement attaqué en justice par de grands distributeurs de musique comme EMI-Time-Warner.

Napster est un système de partage de fichiers où les objets partagés (des fichiers), sont gérés par 50 à 150 serveurs index virtuellement regroupés en un seul méta-serveur routant les nouveaux nœuds vers un des serveurs de ce méta-serveur.

Les serveurs contiennent les titres de fichiers hébergés par le réseau et l'adresse des nœuds qui les mettent à disposition. Ils peuvent aussi jouer le rôle de censeurs : par exemple, dans Napster, seul était autorisé le partage de fichiers audio de format mp3. Pour affirmer cela, les analyses du protocole de Napster sont basées sur la rétro-ingénierie, le protocole Napster n'ayant pas été officiellement diffusé.

Ces analyses ont permis la création de logiciels client-serveur libres, comme Lopster, Xnap ou Teknap, mais aussi de non libres tels que WinMX. Divers serveurs libres ont également vu le jour comme OpenNap et OpenNap-ng. Ces-derniers permettaient de choisir les fichiers partagés, ôtant ainsi la limitation aux fichiers mp3.

Dans Napster, lorsqu'un nœud recherche un objet (un fichier), il envoie au serveur une requête sous forme d'une chaîne de caractères afin de trouver tous les fichiers dont le titre contient cette chaîne. Le serveur répond alors par une liste de nœuds hébergeant l'un de ces fichiers. La recherche peut être limitée au serveur auquel est connecté le nœud demandeur, ou être lancée sur tous les serveurs à la fois. L'échange du fichier s'effectue ensuite directement entre le pair qui héberge le fichier et le pair qui le demande. Seule l'étape du transfert de fichier diffère du modèle client-serveur. L'architecture de ce type de système permet ainsi de partager les mêmes fichiers sur des nœuds différents.

Ce type de systèmes ne permet pas un bon équilibre de charge, car l'évolution du nombre de serveurs supporte difficilement celle du nombre d'utilisateurs, augmentant bien plus rapidement. Ce qui rend difficile l'acceptation de nouveaux utilisateurs au-delà d'une certaine limite. Par ailleurs, cette centralisation créé un maillon faible qui rend ces types de systèmes particulièrement sensibles à des attaques de type déni de service, qui peuvent aller jusqu'à rendre le système inutilisable.

Cette centralisation fut le talon d'achille de Napster : il aura suffit d'attaquer juridiquement le propriétaire des quelques serveurs pour entraîner la destruction de tout le système. La protection contre la censure et la défense de l'anonymat des utilisateurs ne pouvaient être assurées correctement par des systèmes centralisés puisqu'il suffit de contrôler le serveur pour censurer les nœuds, ou de les identifier pour obtenir toutes les informations relatives à leurs activités sur le réseau.

Toutefois, la centralisation permet d'assurer une exhaustivité des réponses, c'est-à-dire que si une réponse existe, elle sera trouvée car chaque serveur connaît tout le réseau. Elle permet également d'assurer une authentification des fichiers partagés de manière simple. L'existence d'un serveur permet aussi de contourner la difficulté posée par les pare-feux, mais le coût pour chaque serveur est tel que cette solution fut abandonnée dans la plupart des systèmes centralisés.
Article Suivant >>>

Page 1 sur 23 pages
Article Précédent Article Suivant