Synthèse générale : cycle complet eD2K/eMule

1. eMule comme ensemble de couches

L’étude complète montre qu’eMule combine plusieurs systèmes :

serveurs eD2K
Kad
client-client
files d'upload
crédits et SecureIdent
Source Exchange
A4AF
MD4/AICH
persistance locale
publication périodique

Aucun de ces mécanismes ne décrit à lui seul « le protocole eMule ».

2. Au démarrage

Le client recharge sa mémoire locale :

server.met
nodes.dat
known.met
part.met
clients.met
preferencesKad.dat
preferences.ini

Chaque fichier joue un rôle différent : bootstrap réseau, mémoire des fichiers, récupération des téléchargements, crédits, identité Kad ou préférences.

3. Rejoindre eD2K et Kad

Le client peut utiliser simultanément :

un serveur eD2K
Kad

Le serveur fournit un Client ID et peut déterminer la joignabilité TCP historique HighID/LowID.

Kad construit une vue distribuée du réseau à partir de contacts et d’identifiants 128 bits.

4. Rechercher

Le serveur interroge son index central.

Kad route vers les nœuds proches de la clé dérivée du mot recherché.

Dans les deux cas, le résultat doit ensuite être ramené à l’identité du contenu : hash eD2K et taille, avec métadonnées associées.

5. Trouver les sources

Une source peut venir de :

serveur connecté TCP
autres serveurs UDP
Kad
Source Exchange
source passive
lien explicite

La provenance n’est pas la preuve que la source sera utile ou joignable.

6. Établir la connexion

TryToConnect() représente une véritable machine de choix du chemin :

TCP direct
Direct UDP Callback
Server Callback
Kad/Buddy Callback
attente optimisée LowID

La sélection dépend de la joignabilité des deux pairs et des informations déjà connues.

7. Handshake

HELLO / HELLOANSWER permettent l’échange de l’identité et des capabilities.

Les extensions importantes incluent notamment :

Unicode
compression
SecureIdent
Source Exchange
Extended Requests
AICH
Large Files
Kad
obfuscation
Captcha
Direct UDP Callback
MultiPacket

Une capability est une annonce de support ; elle ne doit pas être confondue avec une preuve de comportement correct.

8. Confirmer le fichier et les parts

Une fois connecté, le pair doit confirmer qu’il connaît le fichier demandé.

Les échanges de statut de parts indiquent ensuite quelles portions sont annoncées comme disponibles.

Cette information distante reste une assertion ; l’intégrité réelle des données ne sera connue qu’après réception et vérification cryptographique/hash.

9. Entrer en queue

La source distante reçoit une demande d’upload.

Elle applique sa politique locale : limites, doublons, fréquence de demandes, score d’attente, priorité de fichier, crédits éventuels et slots spéciaux.

Le Queue Rank donne une indication de position, mais n’est pas une promesse ferme de date de démarrage.

10. Crédits et SecureIdent

Les crédits sont locaux à chaque client : Alice mémorise ce qu’Akshaan lui a envoyé ; Bob ne reçoit pas automatiquement cette information.

SecureIdent protège l’association entre l’identité persistante et les crédits en utilisant un mécanisme challenge-response avec clé privée/publique.

11. A4AF et NNP

Une même source peut posséder plusieurs fichiers recherchés.

A4AF évite de la traiter comme plusieurs relations indépendantes. Un fichier est actif, les autres restent candidats alternatifs.

DS_NONEEDEDPARTS signifie qu’aucune part utile n’est actuellement disponible pour ce fichier/source ; cela n’implique pas nécessairement une inutilité définitive.

12. Transférer par blocs

Le fichier est divisé en parts eD2K de 9 728 000 octets, puis en requêtes plus petites.

Plusieurs sources alimentent simultanément des zones différentes du même fichier.

Le choix des parts tient compte de la disponibilité/rareté et de l’état local des requêtes déjà réservées.

13. Vérifier

Le hashset MD4 vérifie les parts complètes.

AICH ajoute une structure de hashes plus fine permettant de localiser et récupérer plus précisément des zones corrompues.

La réception d’octets n’est donc pas équivalente à leur acceptation définitive.

14. Fin de téléchargement

À mesure que le nombre de blocs libres diminue, le problème change : il faut éviter que les derniers blocs restent immobilisés derrière une source lente ou indisponible.

Les mécanismes Endgame historiques/mods et la gestion moderne des requêtes cherchent à réduire cette longue traîne sans violer le format de transfert.

15. Devenir source

Lorsque le fichier est complet et validé, il rejoint les fichiers partagés.

Le client peut alors annoncer sa disponibilité :

OP_OFFERFILES vers le serveur
publication de mots-clés Kad
publication de source Kad
éventuelles Notes Kad

Il devient ainsi une nouvelle source pour les autres utilisateurs.

16. La boucle complète

IDENTIFIER
   ↓
RECHERCHER
   ↓
DÉCOUVRIR LES SOURCES
   ↓
SE CONNECTER
   ↓
NÉGOCIER LES CAPACITÉS
   ↓
ENTRER EN FILE
   ↓
REASK / ATTENTE
   ↓
TRANSFÉRER
   ↓
VÉRIFIER
   ↓
RÉPARER SI NÉCESSAIRE
   ↓
TERMINER
   ↓
PARTAGER
   ↓
PUBLIER
   ↓
DEVENIR UNE SOURCE DU RÉSEAU

17. Ce que le serveur n’est pas

Le serveur n’héberge pas les fichiers.

Il indexe des annonces et maintient l’état des clients connectés afin d’offrir recherche, GetSources et callbacks.

18. Ce que Kad n’est pas

Kad n’est pas un transport de fichiers.

Il est principalement un système distribué de découverte et de publication : mots-clés, sources, Notes, routage et assistance de joignabilité.

19. Ce que HighID signifie réellement

HighID indique principalement qu’un client est directement joignable en TCP selon le modèle IPv4 historique d’eD2K.

LowID ne veut pas dire « client lent » ; il signifie qu’un chemin de callback/intermédiation sera nécessaire pour certaines connexions entrantes.

20. Ce que les crédits ne sont pas

Ils ne sont pas une monnaie globale, ni une réputation centrale.

Ils constituent une mémoire bilatérale locale, liée à l’identité du pair et protégée autant que possible par SecureIdent.

21. Ce que l’obfuscation ne fait pas

L’obfuscation rend le trafic moins trivialement identifiable. Elle ne fournit ni anonymat, ni VPN, ni sécurité équivalente à TLS moderne.

22. Pourquoi le protocole a survécu

La stratégie d’évolution est répétitive :

conserver l'ancien format
annoncer une capability
ajouter un nouveau message ou une nouvelle représentation
utiliser l'extension uniquement avec un pair compatible

Large Files, AICH, Source Exchange 2, MultiPacketExt2, obfuscation et Captcha suivent tous, à des degrés différents, cette logique d’extension progressive.

23. Wire protocol et politique locale

Cette distinction traverse toute l’étude.

Le wire protocol fixe surtout :

familles de paquets
opcodes
sérialisation
hashes
identifiants
handshakes
formats compatibles

Le client décide localement de nombreux comportements :

timers
nombre de sources
choix de la prochaine source
score de queue
nombre de slots
sélection des parts
A4AF
DeadSource
anti-spam
cadence pratique de nombreuses opérations

Deux clients peuvent donc être parfaitement interopérables sans appliquer exactement la même stratégie locale.

24. Une donnée distante est une assertion avant d’être une vérité

Cette règle explique beaucoup de protections du logiciel.

Exemples d’assertions distantes :

Queue Rank
Part Status
capabilities annoncées
sources transmises par SX
métadonnées de recherche
statistiques serveur
contacts Kad
ratings/commentaires

À l’inverse, un hash validé sur des données réellement reçues constitue une preuve locale beaucoup plus forte.

25. Résumé final

L’ensemble du protocole peut être ramené à quatre besoins fondamentaux :

QUOI ?
identifier précisément le contenu

OÙ ?
trouver les pairs qui le possèdent

QUAND ET COMMENT ?
organiser les échanges sans saturer les participants ni le réseau

EST-CE CORRECT ?
vérifier les données reçues avant de les considérer comme acquises

Serveurs, Kad, Source Exchange, queues, crédits, A4AF, MD4, AICH, callbacks, Large Files et timers sont les mécanismes bâtis autour de ces quatre problèmes.