En marche vers un eDonkey à deux vitesses ?
Vous le savez sans doute, le créateur d'eDonkey Jed McCaleb s'est plongé dans un nouveau projet de réseau décentralisé : Overnet.
Depuis mai 2002, Lugdunum n'a de cesse de proposer de nouveaux serveurs patchés, qui ont largement influé sur la rapidité globale du réseau. Les plus gros serveurs francophones comme eD2k.ch ou Gruk.org sont aujourd'hui basés sur ces modifications.
Du côté logiciels, les commununautés francophones et allemandes sont très actives. Nawer, après avoir lancé son célèbre NPDonkey, a offert récemment à la communauté un outil de gestion en peer-to-peer des listes de serveurs : NPSelem. Il remplace ou complète avec ce dernier le logiciel eD2kutils, créé par l'allemand BierBaron. Nous pourrions encore citer les plus contestés eDonkeyBot ou Adrenalin.
Un réseau à deux vitesses ?
Si l'ensemble de ces outils améliorent sans conteste l'utilisation d'eDonkey, on ne peut pas nier qu'ils sont réservés à une minorité qui en prend connaissance. Cela n'a cependant pas ou peu d'incidences sur les autres utilisateurs qui, bien que ne profitant pas de ces améliorations, n'en sont pas handicapés.
La question est toute autre avec le nouveau venu, eMule. Nous renouvelons régulièrement notre attachement et notre soutien pour ce nouveau client open-source, né du travail de développeurs allemands, mais il n'est pas sans poser quelques questions quant à l'avenir d'eDonkey, et l'égalité entre les différents utilisateurs du réseau.
En effet, lorsque l'on regarde le code source du logiciel, on s'aperçoit qu'un système de crédits particulier est attaché à la gestion des uploadqueues. C'est-à-dire que selon certains critères, l'utilisateur qui veut télécharger est plus ou moins avancé dans la liste d'attente. Officiellement, la FAQ nous informe qu'un système de crédits existe, basé sur le volume de fichiers. Le coefficient est calculé selon la formule suivante :
coefficient = (2* volume uploadé pour soi) / volume téléchargé de chez soi
Concrètement, plus vous uploadez, plus vous avez des chances de grimper dans les listes d'attente. Les clients eMule mémorisent les utilisateurs qui ont vous ont uploadé des fichiers, même lorsqu'il s'agit de clients eDonkey officiels.
Le paradoxe d'eMule
Rien de bien choquant dans ce principe, qui incite l'ensemble des utilisateurs à partager leurs fichiers. En réalité, les interrogations se cachent ailleurs, dans le code non documenté. En effet, eMule semble pénaliser les utilisateurs d'eDonkeyBot en leur affectant un ratio de 0.9, ceux qui ont une LowID se voient attribués un coefficient de 0.8, tandis que les utilisateurs entrain d'uploader bénéficient d'un ratio de 1.5.
Dans ces ratio actifs, on voit donc que les utilisateurs du très contesté eDonkeyBot auront de plus en plus de mal à télécharger à mesure qu'eMule s'imposera sur le réseau. C'est donc déjà un premier signe de "réseau à deux vitesses" (les utilisateurs en LowID sont déjà naturellement handicapés).
Mais ce sont dans les fonctions non encore actives que se trouvent les plus gros risques de pénalisation des utilisateurs occasionnels d'eDonkey. En effet, on peut repérer dans le code deux variables désactivées, qui semblent annoncer de futures évolutions du client : isemuleclient, et isfriend.
La première devrait permettre d'avantager dans les priorités d'uploadqueue les utilisateurs d'eMule, à un niveau encore indéfini. La deuxième est désactivée mais bien programmée, et permettrai de favoriser les utilisateurs amis listés dans l'onglet "friends" du client, à hauteur d'un coefficient de 2.0.
La FAQ prévient toutefois que le cumul des coefficients seront cadrés dans un minimum de 1.0 et un maximum de 10.0.
Il apparaît donc clairement que les développeurs d'eMule ont en tête de forcer quelque peu le passage à leur client. Il n'y a en soi, rien de négatif à cette démarche, puisqu'il est reconnu par tous et nous les premiers que ce client est bénéfique pour la santé globale du réseau, et plus facile à utiliser pour le novice. Mais on ne peut sans doute pas occulter le fait qu'un grand nombre d'utilisateurs n'auront jamais connaissance de son existence. De plus, les utilisateurs occassionels ou dotés de modems 56K seront peut-être défavorisés. Est-il normal de les handicaper ?
C'est sans doute cette question qui pousse aujourd'hui les développeurs à ne pas activer certaines de ces fonctions cachées...
(Un grand merci à Nawer pour son aide et ses précieuses lumières dans la découverte des fonctions cachées d'eMule)