Large Files et transition 32 → 64 bits

1. Le problème historique des 4 Gio

Les premières structures eD2K reposaient largement sur des tailles et offsets 32 bits. Une limite historique utilisée par eMule est :

OLD_MAX_EMULE_FILE_SIZE = 4290048000

Cette valeur se situe légèrement sous 2^32 afin de rester compatible avec les anciennes hypothèses et découpages du logiciel.

La limite moderne étudiée est :

MAX_EMULE_FILE_SIZE = 0x4000000000

soit :

2^38 octets = 256 Gio

2. La taille d’une part n’a pas changé

La compatibilité Large Files n’a pas consisté à redéfinir le découpage eD2K.

La taille classique reste :

PARTSIZE = 9 728 000 octets

Les gros fichiers contiennent simplement davantage de parts et nécessitent des champs capables d’exprimer des tailles et offsets dépassant 32 bits.

3. Négociation de capacité

Le support Large Files est annoncé pendant le handshake eMule via CT_EMULE_MISCOPTIONS2.

Dans l’implémentation étudiée, le bit Supports Large Files se trouve dans ce champ de capabilities. Le commentaire du code associe également cette capacité au support des tags 64 bits nécessaires pour les grosses tailles.

Le principe d’interopérabilité est donc :

ancien pair
→ continuer à employer les formats historiques

pair Large Files
→ employer les variantes 64 bits lorsqu'elles sont nécessaires

4. Opcodes de transfert 64 bits

Trois variantes importantes apparaissent pour les offsets dépassant 32 bits :

OP_COMPRESSEDPART_I64 = 0xA1
OP_SENDINGPART_I64    = 0xA2
OP_REQUESTPARTS_I64   = 0xA3

Ces variantes évitent de casser la signification des anciens paquets utilisés par les clients qui ne connaissent que les offsets 32 bits.

5. Tags de taille 32 ou 64 bits

Le protocole de tags permet de sérialiser la taille avec une représentation adaptée.

Dans le code étudié, l’écriture de la taille du fichier dépend notamment de IsLargeFile() :

fichier classique → entier 32 bits lorsque possible
fichier Large File → entier 64 bits

Cette coexistence est visible aussi dans aMule et confirme que l’extension n’est pas propre à une seule fonction isolée du client.

6. Serveurs eD2K et Large Files

Le client ne peut pas supposer qu’un serveur comprend les grands fichiers.

Lors de la publication de la liste de fichiers partagés, SendListToServer() filtre les fichiers trop grands lorsque le serveur n’annonce pas la capability Large Files.

Le même principe s’applique aux recherches et échanges associés : le client doit tenir compte des capacités du correspondant afin de ne pas envoyer une représentation impossible à interpréter.

7. Persistance .part.met

Les fichiers de métadonnées des téléchargements ont eux aussi dû évoluer.

Versions importantes étudiées :

PARTFILE_VERSION           = 0xE0
PARTFILE_SPLITTEDVERSION   = 0xE1
PARTFILE_VERSION_LARGEFILE = 0xE2

La présence d’une version spécifique Large File montre que la transition 64 bits ne concerne pas uniquement le réseau : elle traverse également la persistance locale.

8. FileIdentifier et structures modernes

CFileIdentifier centralise progressivement plusieurs éléments d’identité du fichier :

MD4 master
hashset MD4
AICH master
hashset AICH

Les mécanismes plus récents, notamment MultiPacketExt2, utilisent cette abstraction afin de transporter une identité plus riche tout en restant compatible avec l’identité eD2K historique.

9. Leçon d’architecture de la transition 64 bits

La migration n’a pas consisté à annoncer « protocole v2 » et à abandonner l’ancien réseau.

Elle s’est faite par :

capability négociée
+ tags 64 bits
+ opcodes I64
+ formats de persistance adaptés
+ filtrage côté serveur/pair selon capacité

C’est un exemple très clair de la manière dont eMule a conservé l’interopérabilité en faisant cohabiter ancien et nouveau format.