Timeouts, reasks et cadence globale du réseau

1. Pourquoi les timers sont structurants

eMule peut connaître des centaines de sources, plusieurs serveurs et des dizaines de milliers de contacts Kad potentiels. Sans temporisations, chaque client pourrait générer en permanence des demandes de statut, de sources, de callbacks et de publication.

Les timers sont donc une forme de régulation distribuée.

2. Constantes représentatives

Les valeurs relevées dans la branche étudiée incluent notamment :

CONNECTION_TIMEOUT    = 40 s
FILEREASKTIME          = 29 min
SERVERREASKTIME        = 15 min
UDPSERVERREASKTIME     = 30 min
SOURCECLIENTREASKS     = 40 min
SOURCECLIENTREASKF     = 5 min
KADEMLIAREASKTIME      = 1 h
DOWNLOADTIMEOUT        = 100 s
CONSERVTIMEOUT         = 25 s
MIN_REQUESTTIME        = 10 min
MAX_PURGEQUEUETIME     = 1 h
PURGESOURCESWAPSTOP    = 15 min

À cela s’ajoutent les cadences de publication Kad vues au dossier précédent.

3. Le reask de fichier d’environ 29 minutes

Lorsqu’un client attend dans la file d’une source, il n’est pas nécessaire de garder une connexion TCP ouverte pendant toute l’attente.

Le client peut revenir périodiquement pour :

confirmer qu'il demande toujours le fichier
obtenir l'état distant actualisé
mettre à jour son Queue Rank lorsque disponible
rafraîchir les informations de parts

La valeur emblématique est FILEREASKTIME ≈ 29 min.

4. UDP reask

Lorsque les deux pairs possèdent les capacités nécessaires et que l’état réseau le permet, certaines mises à jour de file peuvent passer par UDP.

Le but est de réduire le coût d’une reconnexion TCP complète pour une petite quantité d’information.

Si le chemin UDP n’est pas utilisable, le client conserve un chemin TCP de repli.

5. Les reasks ne forment pas un unique timer fixe

La cadence effective dépend de nombreux états :

source normale
source firewalled
NNP
A4AF
source exchange
connexion en cours
source morte temporaire
queue pleine
fichier stoppé

Des délais spécifiques et backoffs empêchent qu’un pair soit interrogé de façon répétitive lorsqu’aucun progrès utile n’est attendu.

6. DeadSource n’est pas un bannissement

La DeadSourceList agit comme un cooldown : un endpoint ayant récemment échoué peut être temporairement ignoré avant d’être redécouvert ou retenté.

L’étude du cycle de vie a montré que les portées locale/globale et les durées peuvent varier selon le type de source et la raison de l’échec.

7. Purge de la queue

MAX_PURGEQUEUETIME ≈ 1 h concerne la conservation d’une entrée distante sans activité suffisante. Cette logique est distincte du reask de fichier lui-même.

8. Publication Kad

Les publications ont elles aussi une cadence destinée à éviter l’inondation :

sources  ≈ 5 h
keywords ≈ 24 h
notes    ≈ 24 h

Une boucle interne espace aussi les opérations de store individuelles ; tout n’est pas envoyé en rafale au même instant.

9. Timers de serveur

Deux notions différentes doivent être séparées :

re-demander les sources d'un fichier au serveur connecté
interroger d'autres serveurs en UDP

Les ordres de grandeur étudiés sont respectivement 15 et 30 minutes, avec une file locale qui regroupe et espace les demandes TCP.

10. Timers et protocole

La plupart de ces constantes ne font pas partie d’une spécification wire obligatoire.

Elles représentent des politiques de l’implémentation eMule qui se sont néanmoins imposées comme comportement de fait du réseau.

Il faut donc distinguer :

format du message
≠
moment où le logiciel décide de l'envoyer

11. Résumé du dossier 24

Le réseau eMule repose autant sur ce qu’il n’envoie pas que sur ce qu’il envoie. Les temporisations empêchent la connaissance de centaines de sources de devenir des centaines de connexions et de requêtes permanentes.