Cycle complet de publication d’un fichier

1. Avant le réseau : identifier le fichier

Un fichier partagé doit d’abord être connu localement. eMule construit son identité à partir du hash eD2K et du hashset de parts ; les versions compatibles AICH peuvent également conserver l’identité AICH.

Les informations connues sont persistées notamment dans known.met afin d’éviter de retraiter inutilement les mêmes fichiers à chaque démarrage.

2. Publication serveur : OP_OFFERFILES

Côté serveur eD2K, le mécanisme central est OP_OFFERFILES.

Le message annonce des fichiers partagés au serveur. Il transporte les identifiants et métadonnées permettant au serveur de construire son index.

Le serveur ne reçoit jamais le contenu du fichier lui-même.

Il reçoit essentiellement une affirmation du type :

ce client peut servir le FileHash X
voici son nom, sa taille et ses métadonnées

3. CSharedFileList::SendListToServer()

Dans la branche étudiée, cette fonction applique plusieurs règles avant publication :

• ne prendre que les fichiers éligibles et pas déjà publiés pour la séquence courante ;
• ne publier les Large Files que si le serveur annonce SupportsLargeFilesTCP() ;
• ordonner la sélection en tenant compte de la priorité d’upload ;
• respecter le soft-file limit fourni par le serveur ;
• limiter localement à 200 fichiers par paquet ;
• construire chaque entrée via CreateOfferedFilePacket() ;
• compresser le paquet lorsque le serveur annonce la compression correspondante.

4. Marqueurs de fichier complet/incomplet

Les variantes modernes des offres peuvent utiliser des valeurs spéciales dans certains champs IP/port afin d’indiquer l’état complet ou incomplet du fichier au serveur compatible.

Ce détail est une convention d’implémentation/extension et non une preuve que le serveur transporte le fichier.

5. Publication Kad : trois objets différents

Kad ne publie pas un unique enregistrement « fichier ».

L’étude distingue au moins :

publication de mots-clés
publication de source
publication de notes

Ces trois opérations répondent à trois besoins différents.

6. Publication de mots-clés

Pour rendre un fichier trouvable par recherche textuelle, eMule extrait des mots-clés et calcule les clés Kad correspondantes.

Le code étudié s’appuie notamment sur CPublishKeyword.

Caractéristiques relevées :

• seuls les fichiers complets sont utilisés pour la publication de mots-clés dans le chemin étudié ;
• un envoi de publication est limité à un nombre fini d’identifiants de fichiers ;
• la valeur étudiée est de 150 File IDs par publication de mot-clé avant rotation/continuation.

7. Publication de source

La publication de source répond à la question :

qui possède actuellement des données du FileHash X ?

Cette information est temporaire et doit être rafraîchie périodiquement.

Avant de publier, le client tient compte de sa capacité réelle à être contacté : client ouvert, client firewalled avec Buddy, ou possibilité de callback UDP direct lorsqu’elle est disponible.

8. Publication de notes

Les Notes Kad transportent des métadonnées sociales associées au hash : nom observé, rating, description/commentaire et, avec les pairs compatibles, taille du fichier.

Elles sont indépendantes du fait d’être une source du fichier.

9. Expiration et republication

Kad doit être compris comme un ensemble d’annonces temporaires.

Les ordres de grandeur relevés dans l’implémentation étudiée sont :

source Kad     ≈ 5 heures
mot-clé Kad    ≈ 24 heures
notes Kad      ≈ 24 heures

La cadence d’émission est elle-même limitée ; la publication n’inonde pas immédiatement le réseau avec toutes les entrées disponibles.

10. Publication et état réel

Une publication n’est pas une copie permanente de la vérité. Elle représente l’état annoncé au moment de l’enregistrement puis expire.

Le système reste donc cohérent grâce à une boucle :

état local
→ publication
→ durée de vie
→ expiration
→ republication si l'information reste vraie