Tout simplement en cliquant sur ce bouton qui est situé dans le haut à droite du donkey, si vous êtes connectés à un serveur.
Si l'ID est nul (égal à 0), c'est que vous n'êtes pas connecté à un serveur !
Si l'ID est faible (inférieur à 16 million), on dit que c'est un Low ID
Si l'ID est élevé (supérieur à 16 million), on dit que c'est un High ID.
Attribution de l'ID
L'ID est attribué par le serveur en début de connexion.
Quand un client se connecte au serveur edonkey, le serveur tente d'ouvrir une connexion TCP vers le port 4662 du client.
Si cette connexion se passe bien, le serveur attribue un High ID au client.
Si la connexion échoue (à cause d'un parefeu ou d'un problème de délai réseau) le serveur attribue un 'Low ID', grosso modo un numéro interne du serveur. Un Low ID ne permet pas de retrouver l'adresse IP alors qu'un High ID le permet.
Si un High ID est attribué par le serveur, ce High ID est exactement l'adresse IP du client réécrite différement :
Si l'adresse IP du client est A.B.C.D, on ecrit sous forme héxadécimale
aa.bb.cc.dd , puis on inverse l'ordre des octets et on met sous la forme : ddccbbaa, puis on passe en décimal : on obtient l'ID.
L'opération peut se faire dans l'autre sens.
Ce petit formulaire vous permet de passer de l'ID à l'IP et vice versa.
Ce mécanisme explique que si un client change de serveurs edonkey, en général il conserve son ID, car son adresse IP ne change pas pendant une session Internet.
Pour que l'adresse IP change, il faut se déconnecter du réseau Internet, se reconnecter et supposer que le provider ne vous re-attribue pas l'IP précédente et en choisisse une autre.
Utilisation de l'ID
Un client edonkey B doit contacter un autre client A (peer to peer) pour obtenir une 'source' ou morceau de fichier. Or pour contacter un peer, il faut connaitre son adresse IP.
Cette adresse IP, le donkey la détermine grace à l'ID du peer A que le serveur lui a communiqué, dans le résultat d'un search.
Si le ID de A est un 'HighID', B tente directement une connexion TCP vers le port 4662 de A. Le peer to peer en natif !
Si le ID de A est 'faible' (par opposition à High ID), l'adresse IP ne peut pas être calculée, le peer n'est pas joignable directement.
Pour le joindre, il faut que le client B envoie une trame spéciale au serveur du client A (sur son port UDP 4665)
Sur réception d'une demande de ce type, le serveur envoie au client A sur sa liaison TCP 4661 la demande du client B, en indiquant l'adresse IP et le port du client B. Le client A peut ensuite essayer de contacter le client B sur son port 4662.
Ce mécanisme est impossible si A et B sont en LowID.
De plus, la demande du client B est envoyée en UDP au serveur de A, or UDP est un protocole moins fiable que TCP. Les serveurs étant saturés, une bonne partie des trames UDP 4665 sont perdues sur le réseau Internet.
Conclusions : si un client edonkey obtient un Low ID, il n'est pas joignable par un autre client LowID. Il réduit donc les probabilités de croisement des sources.
Il engendre une surcharge de son serveur qui sera sollicité par les clients edonkey désireux d'obtenir des sources chez le LowID.
Les serveurs ayant une bande passante limitée sont obligés de réduire leur nombre maximal d'utilisateurs. le réseau edonkey fonctionne moins bien.
L'expérimentation commencée le 22 mai sur Lugdunum et Radio-Goth a permis de constater la baisse du trafic engendrée lorsque le taux de LowID diminue sur un serveur. Fran_48 a fait une étude mathématique à ce sujet.
Si trop de gars ont un LowID, les téléchargements ne peuvent plus se faire, c'est mathématique (par le jeu des probabilités)
Deux clients ayant un LowID ne peuvent pas communiquer entre eux.
Deux clients ayant un High ID peuvent communiquer dans les deux sens : situation optimale pour eux mais aussi pour la bonne santé du réseau edonkey.
Les serveurs ne sont pas sollicités pour jouer le rôle de relai. Les serveurs effectuent des recherches, ce pour quoi ils sont faits.
.
Qu'est-ce qui peut expliquer un Low ID
Un parefeu, quelque part, bloque le port 4662 du client.
Merci de consulter la FAQ pour configurer proprement votre parefeu si vous en avez un (Windows XP intègre un parefeu en standard)
Lien pour configurer le parefeu de Windows XP
Un routeur ADSL n'a pas été configuré pour mapper le port 4662 en provenance du réseau Internet vers la machine edonkey intérieure, sur le port 4662. Consultez le chapitre suivant pour quelques conseils.
Vous avez une adresse IP de la forme A.B.C.O (dernier chiffre nul). Ce cas est fort heureusement exceptionnel.
Plusieurs personnes partagent le même accès Internet. Quand une même adresse IP est utilisée plus d'une fois, le serveur alloue des 'Low ID'.
Nous avons mis en place (le 17 mai 2002) sur lugdunum un mécanisme qui refuse plus d'une connexion en provenance d'une même adresse IP (module iplimit de netfilter).
Ce refus va permettre de contourner un bug du protocole edonkey :
Quand un client se déconnecte, il arrive quelquefois que le serveur ne l'apprenne pas tout de suite.
Le serveur gardant en mémoire la connexion précédente, alloue alors un LowID au client qui se reconnecte à lui trop vite.
Nous préférons refuser le doublon et ainsi éviter l'obtention d'un LowID.
Si vous avez quelquefois un problème pour vous connecter à lugdunum, c'est peut être à cause de ce nouveau mécanisme.
Nouveau dans la version 16.38.p36 :
Le bug du dserver a enfin été trouvé et corrigé dans cette version.
Nouveau dans la version 16.38.p56 :
Le serveur est maintenant capable d'allouer des ID hauts pour des personnes utilisant la même adresse IP, du moment qu'elles utilisent des ports différents.
Deux clients edonkey partageant la même adresse IP auront le même ID, mais des ports distincts.
Votre port 4662 est mappé non pas sur votre client edonkey mais vers une autre application. Par exemple le port 80 arrive en général sur un serveur HTTP.
Depuis la version 16.38.p63 (17 octobre 2002) le serveur détecte ce cas de figure et vous attribue un LOWID.
Le serveur détecte même les cas où le port 4662 arrive sur un autre client edonkey... Attention donc à bien configurer vos clients pour ceux qui en utilisent plusieurs sur la même adresse IP.
Le serveur a sa bande passante saturée, et n'arrive pas à contacter le client en moins de huit secondes.
Le serveur edonkey attend très peu de temps pour prendre sa décision.
lugdunum essaie de contrer ce problème en utilisant le 'traffic shaping' de linux : le port 4662 a été mis en classe prioritaire pour passer devant les autres paquets edonkey : lugdunum alloue plus souvent un High ID que d'autres serveurs.
Le client a sa bande passante saturée. Ceci peut arriver pour de multiples raisons.
Nouveau dans la version 16.38.p36 :
Le bug du dserver a enfin été trouvé et corrigé dans cette