Difference between revisions of "FAQ ed2k-fr"

From AMule Project FAQ
Jump to: navigation, search
m (Reordered language selection)
(traduction du chapitre en "Are there any limitations on the ED2K network?")
Line 24: Line 24:
 
Remarquez que les client n'envoient que '''un''' chunk à la fois à un autre client. Même si un client est à la fois dans la file d'attente des envois pour deux fichiers différents chez un même utilisateur, et arrive en premier pour ses deux fichiers alors cet utilisateur ne lui enverra qu'un seul fichier à la fois (selon l'application ED2K que le client utilise, l'autre envoi restera probablement à une priorité maximale dans la file des envois, mais il ne commencera pas tant que l'autre chunk n'aura pas été envoyé complètement).
 
Remarquez que les client n'envoient que '''un''' chunk à la fois à un autre client. Même si un client est à la fois dans la file d'attente des envois pour deux fichiers différents chez un même utilisateur, et arrive en premier pour ses deux fichiers alors cet utilisateur ne lui enverra qu'un seul fichier à la fois (selon l'application ED2K que le client utilise, l'autre envoi restera probablement à une priorité maximale dans la file des envois, mais il ne commencera pas tant que l'autre chunk n'aura pas été envoyé complètement).
  
Si les deux utilisateurs ont un HighID le transfert sera effectué directement de client à client (Pair-à-Pair), mais si un des clients à un LowID, la connection sera établie par l'intermédiaire du serveur parce que les LowID ne peuvent pas accepter une connection entrante. A cause de ça, deux clients ayant un LowID '''ne peuvent pas''' se connecter entre eux.
+
Si les deux utilisateurs ont un HighID le transfert sera effectué directement de client à client (Pair-à-Pair), mais si un des clients à un LowID, la connexion sera établie par l'intermédiaire du serveur parce que les LowID ne peuvent pas accepter une connexion entrante. A cause de ça, deux clients ayant un LowID '''ne peuvent pas''' se connecter entre eux.
  
 
== Kademlia c'est quoi ? ==
 
== Kademlia c'est quoi ? ==
  
Kademlia est l'évolution naturelle du réseau ED2K. Kademlia est le futur. Regardez [[FAQ_eD2k-Kademlia#Are_there_any_limitations_on_the_ED2K_network?|Y a t il des limitation au réseau ED2K?]] pour plus d'information sur la necessité de Kademlia.
+
Kademlia est l'évolution naturelle du réseau ED2K. Kademlia est le futur. Regardez [[#Y a t il des limitation au réseau ED2K?]] pour plus d'information sur la nécessité de Kademlia.
  
 
Parce que Kademlia est un réseau décentralisé, il évite le goulot d'étranglement qui était précédemment causé par le besoin de serveurs (bien que [[Lugdunum]] ait accompli un grand travail dans la réduction de ce goulet d'étranglement). Maintenant au lieu de vous connecter à un serveur vous ne faites que vous connecter à un client (avec un port et une adresse IP connus), qui supporte le réseau Kademlia. Cela s'appelle le "Boot Strapping".
 
Parce que Kademlia est un réseau décentralisé, il évite le goulot d'étranglement qui était précédemment causé par le besoin de serveurs (bien que [[Lugdunum]] ait accompli un grand travail dans la réduction de ce goulet d'étranglement). Maintenant au lieu de vous connecter à un serveur vous ne faites que vous connecter à un client (avec un port et une adresse IP connus), qui supporte le réseau Kademlia. Cela s'appelle le "Boot Strapping".
Line 47: Line 47:
  
 
Pour éviter de partager des fichiers corrompus, le protocole ED2K divise chaque fichier en un certain nombre de morceaux, qui sont appelés ''chunk'', et ensuite chacun des chunks est réduit à son tour en petits morceaux (lisez plus bas pour savoir ce que sont ces petits morceaux). Chaque chunk a une taille de 9.28MB, ainsi un fichier de 15MB sera divisé en deux chunks (9.28MB + 5.72MB), un fichier de 315KB sera un seul chunk et un fichier de 100MB sera divisé en 11 chunks (10x9.28MB + 7.2MB).
 
Pour éviter de partager des fichiers corrompus, le protocole ED2K divise chaque fichier en un certain nombre de morceaux, qui sont appelés ''chunk'', et ensuite chacun des chunks est réduit à son tour en petits morceaux (lisez plus bas pour savoir ce que sont ces petits morceaux). Chaque chunk a une taille de 9.28MB, ainsi un fichier de 15MB sera divisé en deux chunks (9.28MB + 5.72MB), un fichier de 315KB sera un seul chunk et un fichier de 100MB sera divisé en 11 chunks (10x9.28MB + 7.2MB).
 +
 +
== Y a t il des limitation au réseau ED2K ? ==
 +
Pas beaucoup mais il y en a ; il en existe deux naturelles et une limite "contrainte".
 +
 +
Les deux limites naturelles ont déjà été mentionnées. La première touche les utilisateurs en LowID (les transfert de leurs données doit passer par un serveur et deux LowID ne peuvent pas partager des fichiers ensemble). La seconde est que ED2K est un protocole p2p qui a besoin de serveurs pour effectuer les connections pair à pair. Cela soulève plusieurs problèmes de goulot d'étranglement, de confidentialité et d'extensibilité (si un serveur est déconnecté, une grosse partie du réseau se déconnecte en même temps que lui). Ce problème là est résolut dans le protocole Kademlia.
 +
 +
Pour ce qui est de la limite "contrainte", elle ne sert qu'à s'assurer que les clients partagent et que le reseau ED2K ne va pas disparaître :
 +
*les clients qui ont une limite d'upload à X KBps (où 0 <= X <= 3.99) peuvent downloader à un maximum de X*3 KBps ;
 +
*les clients qui ont une limite d'upload à Y KBps (où 4 <= Y <= 9.99) peuvent downloader à un maximum de Y*4 KBps ;
 +
*les clients qui upload à plus de 10 KBps (10 inclus) n'ont pas de limitations.
 +
 +
Cette limitation est codé dans l'application cliente donc elle peut être outre-passé par un hack du code source mais cela mènerait certainement à un bannissement par le serveur auquel une telle application se connecterait.
 +
 +
Aussi, tous les clients sont obligés d'allouer au moins trois slots d'upload ; il est donc impossible d'allouer plus que (limite_d'upload)/3 KBps par slot.
 +
 +
Il y a encore une limite : la taille maximale d'un fichier est de 256GB (274877906944 bytes). Une ancienne limite (jusqu'à eMule 0.46 et aMule 2.1.*) était un peu en dessous de 4 GB (exactement 4294967295 bytes, bien que aMule ne supportait que 4290048000 bytes).
 +
 +
De plus, et ce n'est pas une limitation du protocole ed2k mais des serveurs eux-même, les serveurs ne renvoient que 300 réponses pour vos recherches et donc, n'espérez pas plus de résultats.
 +
 +
Du coté client, les noms de fichier sont généralement limités à 161 [[character|caractères]].

Revision as of 14:25, 11 January 2009

English | Deutsch | Español | Français | Italiano | Nederlands | Polish | Russian

ED2K, c'est quoi ?

A la base ED2K est un protocole pour le client P2P (pair-à-pair) eDonkey2000, c'est de là que vient son nom. C'est un protocole basé sur une interaction serveur-client, avec la capacité d'échanger les sources entre les clients.

Le réseau ED2K est basé sur les serveurs à la différence des réseaux de P2P tels que Kazaa, ce qui signifie que la première chose que vous faites lorsque vous lancez eMule est de vous connecter à un serveur (manuellement ou automatiquement).

Une fois connecté avec succès à un serveur, le client peut chercher, soit localement (au serveur connecté) soit globalement (tous les serveurs), n'importe quel fichier et le serveur questionné fournira au client une liste de tous les fichiers qui répondent aux paramètres de recherche.

Si l'utilisateur démarre un téléchargement, le client demandera alors au serveur des sources et le serveur va renvoyer le nom (sous la forme d'adresse IP) des clients qui ont répondu qu'ils avaient bien le fichier demandé.

Ensuite le client distant va commencer à envoyer un chunk entier à votre client aussitôt que vous serez le premier dans la file d'attente. Et, quand le chunk a été envoyé en entier, vous serez effacé de sa file des envois. Cette façon qu'ont les différents chunks de se répandre autour du réseau ED2K fait que même si personne n'a à un instant donné le fichier complet, et bien il peut être complété en téléchargeant les différents chunks à partir de différentes personnes ( c'est bien connu que les gens arrêtent de partager un fichier une fois qu'il à été complété).

Remarquez que les client n'envoient que un chunk à la fois à un autre client. Même si un client est à la fois dans la file d'attente des envois pour deux fichiers différents chez un même utilisateur, et arrive en premier pour ses deux fichiers alors cet utilisateur ne lui enverra qu'un seul fichier à la fois (selon l'application ED2K que le client utilise, l'autre envoi restera probablement à une priorité maximale dans la file des envois, mais il ne commencera pas tant que l'autre chunk n'aura pas été envoyé complètement).

Si les deux utilisateurs ont un HighID le transfert sera effectué directement de client à client (Pair-à-Pair), mais si un des clients à un LowID, la connexion sera établie par l'intermédiaire du serveur parce que les LowID ne peuvent pas accepter une connexion entrante. A cause de ça, deux clients ayant un LowID ne peuvent pas se connecter entre eux.

Kademlia c'est quoi ?

Kademlia est l'évolution naturelle du réseau ED2K. Kademlia est le futur. Regardez #Y a t il des limitation au réseau ED2K? pour plus d'information sur la nécessité de Kademlia.

Parce que Kademlia est un réseau décentralisé, il évite le goulot d'étranglement qui était précédemment causé par le besoin de serveurs (bien que Lugdunum ait accompli un grand travail dans la réduction de ce goulet d'étranglement). Maintenant au lieu de vous connecter à un serveur vous ne faites que vous connecter à un client (avec un port et une adresse IP connus), qui supporte le réseau Kademlia. Cela s'appelle le "Boot Strapping".

Une fois connecté, et selon votre capacité à accepter des connections entrantes, on vous donne le status de "ouvert" ou "derrière un firewall", ce qui est similaire au HighID et LowID du réseau ED2K. Ensuite on vous donne une identification.

Pour le moment, les utilisateurs "derrière un firewall" ne sont pas supportés par le réseau kademlia. Ils ne recevront donc pas d'identification et seront incapables de se connecter. Le support des gens "derrière un firewall" sera ajouté ultérieurement.

Pendant la recherche chaque client agit comme un petit serveur et reçoit la responsabilité de certaines sources ou mots clés. Cela ajoute de la complexité à trouver des sources parce qu'il n'y a plus un serveur central à questionner, mais au lieu de cela il faut propager les requêtes à travers le réseau.

Actuellement Kademlia n'est pas supporté par aMule, mais il le sera bientôt.

Est ce que Kademlia c'est la même chose que Overnet?

En un mot : non. Overnet est l'évolution sans serveur naturelle du logiciel eDonkey, alors que Kademlia est l'évolution sans serveur naturelle des clients *Mule. DONC, c'est le même principe, mais suivant des règles différentes. Pour apprendre le fonctionnement de Overnet, réferez vous à http://www.edonkey2000.com/documentation/how_on.html mais gardez à l'esprit que le développement de Overnet sera fermé jusqu'a ce qu'il atteigne la version 1.0 alors que le développement de Kademlia est totalement ouvert depuis le début.

Qu'est ce qu'un chunk?

Pour éviter de partager des fichiers corrompus, le protocole ED2K divise chaque fichier en un certain nombre de morceaux, qui sont appelés chunk, et ensuite chacun des chunks est réduit à son tour en petits morceaux (lisez plus bas pour savoir ce que sont ces petits morceaux). Chaque chunk a une taille de 9.28MB, ainsi un fichier de 15MB sera divisé en deux chunks (9.28MB + 5.72MB), un fichier de 315KB sera un seul chunk et un fichier de 100MB sera divisé en 11 chunks (10x9.28MB + 7.2MB).

Y a t il des limitation au réseau ED2K ?

Pas beaucoup mais il y en a ; il en existe deux naturelles et une limite "contrainte".

Les deux limites naturelles ont déjà été mentionnées. La première touche les utilisateurs en LowID (les transfert de leurs données doit passer par un serveur et deux LowID ne peuvent pas partager des fichiers ensemble). La seconde est que ED2K est un protocole p2p qui a besoin de serveurs pour effectuer les connections pair à pair. Cela soulève plusieurs problèmes de goulot d'étranglement, de confidentialité et d'extensibilité (si un serveur est déconnecté, une grosse partie du réseau se déconnecte en même temps que lui). Ce problème là est résolut dans le protocole Kademlia.

Pour ce qui est de la limite "contrainte", elle ne sert qu'à s'assurer que les clients partagent et que le reseau ED2K ne va pas disparaître :

  • les clients qui ont une limite d'upload à X KBps (où 0 <= X <= 3.99) peuvent downloader à un maximum de X*3 KBps ;
  • les clients qui ont une limite d'upload à Y KBps (où 4 <= Y <= 9.99) peuvent downloader à un maximum de Y*4 KBps ;
  • les clients qui upload à plus de 10 KBps (10 inclus) n'ont pas de limitations.

Cette limitation est codé dans l'application cliente donc elle peut être outre-passé par un hack du code source mais cela mènerait certainement à un bannissement par le serveur auquel une telle application se connecterait.

Aussi, tous les clients sont obligés d'allouer au moins trois slots d'upload ; il est donc impossible d'allouer plus que (limite_d'upload)/3 KBps par slot.

Il y a encore une limite : la taille maximale d'un fichier est de 256GB (274877906944 bytes). Une ancienne limite (jusqu'à eMule 0.46 et aMule 2.1.*) était un peu en dessous de 4 GB (exactement 4294967295 bytes, bien que aMule ne supportait que 4290048000 bytes).

De plus, et ce n'est pas une limitation du protocole ed2k mais des serveurs eux-même, les serveurs ne renvoient que 300 réponses pour vos recherches et donc, n'espérez pas plus de résultats.

Du coté client, les noms de fichier sont généralement limités à 161 caractères.