🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page s'adresse à vous si vous voulez savoir ce que les moteurs race et hoard font réellement de différent, s'il faut ajouter un troisième moteur, et quels réglages de moteur ont un effet. À la fin, vous saurez en quoi les deux rôles diffèrent, comment ajouter, supprimer et utiliser un moteur supplémentaire, comment déplacer ou dupliquer un torrent entre moteurs, quels protocoles pair à pair sont actifs, et ce que les moteurs ne savent pas faire en 4.4. Les emplacements de téléchargement, les limites de partage et les limites de débit sont aussi par moteur ; ils ont leur propre page : File d'attente, limites de partage et de débit.

Un moteur est une session BitTorrent à l'intérieur du processus hydranos. Il n'y a pas de processus moteur séparé. Chaque moteur possède :

• sa table de torrents et son gestionnaire de disque (un pool de fichiers ouverts) ;
• un listener TCP sur son port d'écoute, et un socket uTP sur le même numéro de port (UDP) ;
• sa propre file de connexions sortantes, avec ses propres limites de connexions ;
• son propre nœud DHT et son LSD (découverte de pairs locaux), s'ils sont actifs ;
• son propre planificateur d'annonces, et son propre scrape des torrents pas encore annoncés ;
• son propre peer id, tiré à chaque démarrage (-HY, la version, -, puis 12 caractères aléatoires), envoyé dans ses annonces et dans chaque handshake, entrant comme sortant ;
• son propre état de reprise, dans <config dir>/<engine id>/state.db.

Les métadonnées des torrents (les octets du .torrent) ne sont pas dans le moteur : elles vivent dans le store, hydra.db, partagé par tous les moteurs. Voir Architecture pour les fichiers sur disque.

Chaque instance fait toujours tourner deux moteurs, race et hoard, construits à partir des sections [race] et [hoard] de default.toml. Vous pouvez en ajouter d'autres (voir Ajouter des moteurs plus bas). Les moteurs sont construits une seule fois, au démarrage : ajouter ou supprimer un moteur, et la plupart des réglages de moteur, demandent un redémarrage (les réglages appliqués à chaud sont listés sous Réglages par moteur qui s'appliquent).

flowchart LR
    subgraph P["processus hydranos"]
        subgraph R["moteur race, rôle race"]
            R1["listener TCP + uTP<br/>port 16171"]
            R2["file de connexions, DHT, LSD"]
            R3["planificateur d'annonces"]
            R4["race/state.db"]
        end
        subgraph H["moteur hoard, rôle hoard"]
            H1["listener TCP + uTP<br/>port 16172"]
            H2["file de connexions, DHT, LSD"]
            H3["planificateur d'annonces"]
            H4["hoard/state.db"]
        end
        subgraph V["moteur vpn1, exemple de moteur supplémentaire"]
            V1["listener TCP + uTP<br/>port 16473"]
            V2["file de connexions, DHT, LSD"]
            V3["planificateur d'annonces"]
            V4["vpn1/state.db"]
        end
    end
    R2 --> DEF["route par défaut<br/>pas de bind_interface"]
    R3 --> DEF
    H2 --> DEF
    H3 --> DEF
    V2 --> WG1["wg1<br/>bind_interface de vpn1"]
    V3 --> WG1
    DEF --> NET["pairs, trackers, nœuds DHT"]
    WG1 --> NET
    IN["pairs entrants"] --> R1
    IN --> H1
    IN -- "par wg1" --> V1

Les pairs entrants atteignent chaque moteur sur son propre port. Depuis la 4.4, tout ce qu'un moteur envoie (connexions vers les pairs, annonces, DHT, LSD, webseeds, scrapes) sort par la sortie propre à ce moteur, avec son propre peer id : voir Ce qu'un moteur supplémentaire isole plus bas.

Chaque moteur a un rôle, race ou hoard. Le rôle est un comportement, pas un nom : un moteur supplémentaire vpn1 de rôle race annonce et est drainé comme le moteur race. Tout ce qui n'est pas race se comporte comme hoard pour les annonces.

Tout le reste est le même code pour les deux rôles, débit compris : un torrent race ne télécharge ni n'envoie plus vite qu'un torrent hoard. Sont aussi communs : le planificateur d'annonces, le rythme par tracker, le disjoncteur, les événements BEP 3, le scrape des torrents pas encore annoncés, la DHT, PEX, LSD, les trackers UDP, les webseeds, le balayage de transit, ainsi que la file de téléchargement, les limites de partage et les limites de débit (File d'attente, limites de partage et de débit). Les règles d'annonce sont détaillées dans Trackers & annonces ; le drain et le refus d'ajout dans Drain race & graduation.

La 4.3 voulait qu'un torrent race en téléchargement se ré-annonce toutes les 5 s, puis toutes les 30 s, mais ne l'a jamais fait ; la 4.4 abandonne volontairement cette cadence : après une annonce réussie, race attend l'intervalle du tracker comme hoard. Utilisez Re-annoncer (Reannounce) dans le menu contextuel (60 s de délai minimum par torrent) si vous avez besoin d'une annonce plus tôt.

L'onglet Race liste les torrents de tous les moteurs de rôle race et l'onglet Hoard ceux de tous les moteurs de rôle hoard ; les lignes d'un moteur supplémentaire portent son nom (local-vpn1). Un torrent tenu par deux moteurs fait deux lignes, chacune avec les chiffres de sa propre copie.

Quelques fonctions regardent l'identifiant de moteur race ou hoard ; un moteur supplémentaire de même rôle n'en profite donc pas :

• L'enregistreur de chronologie race (la Chronologie (Timeline) d'un torrent race) ne surveille que le moteur race.
• Les cartes Moteur Race (Race engine) et Moteur Hoard (Hoard engine) de la Vue d'ensemble (Overview) visent les identifiants race et hoard ; tout autre moteur a sa propre carte Engine {id} (Supervision & journaux). /api/hoard/torrents ne liste que le moteur hoard, quelle que soit la requête (pour un autre moteur : GET /api/engines/<id>/torrents). Les routes d'écriture par torrent sous /api/race/… et /api/hoard/… (catégorie, emplacement, tags) visent elles aussi l'identifiant, sauf si vous ajoutez ?engine=. Tout ce qui est sous ces préfixes n'est pas lié à l'identifiant : /api/race/torrents, /api/race/page et /api/hoard/page listent tous les moteurs de ce rôle, et /api/hoard/torrents/<hash>/verify trouve le torrent dans n'importe quel moteur. Chaque moteur est aussi joignable via /api/engines/<id>/… (voir API REST).

En cas de doute, classez vos catégories en Hoard. Race sert à faire la course sur les uploads frais, et le drain race peut supprimer des torrents avec leurs données quand un disque race se remplit. Les torrents importés depuis qBittorrent arrivent toujours dans hoard.

C'est la catégorie qui choisit le moteur : une catégorie en mode hoard envoie un torrent vers hoard, tout autre mode vers race (règle et refus : Catégories & routage).

• Race : les torrents que vous récupérez dès leur publication (autobrr, releases Sonarr/Radarr sur lesquelles vous voulez gagner la course), sur un disque que vous voulez voir vidé automatiquement. Race annonce à tous les trackers, réessaie rapidement un torrent pas encore enregistré, et le drain supprime ou fait graduer les anciens torrents quand le disque se remplit.
• Hoard : tout ce que vous gardez et seedez pendant des mois : imports depuis un autre client, téléchargements terminés qui ont gradué, une bibliothèque que vous ajoutez avec des données existantes. Hoard annonce poliment (premier palier qui répond seulement) et ses emplacements de téléchargement empêchent un gros lot de tout télécharger en même temps.

Hoard ne supprime jamais rien de lui-même. Ne choisissez race que pour des torrents que vous comptez laisser partir : il les place dans chaque essaim dès les premières minutes, et son drain les évacue ensuite (Drain race & graduation).

Un moteur supplémentaire est tout moteur autre que race et hoard. Raison typique : un port d'écoute séparé, lié à sa propre interface réseau, pour que les pairs entrants de certains torrents vous joignent par un autre tunnel.

Depuis l'interface : onglet Nodes › This node › + Add an engine :

Ajouter (Add) écrit un bloc engine dans default.toml et affiche The config changed. Engines are built at boot, so this takes a restart. avec Redémarrer maintenant (Restart now). Rien ne démarre avant le redémarrage. Le tableau sous This node montre ensuite le moteur avec l'état de son Socket : listening ou n'écoute pas (not listening) (par exemple quand l'interface est tombée).

Un nouveau moteur supplémentaire hérite du proxy SOCKS5, du proxy d'annonce et de l'interface de son rôle, mais pas du tunnel WireGuard, du port gluetun, du port PROXY-v2 ni du direct assumé (direct on purpose) de race ou de hoard. Ce que le kill switch en fait ensuite dépend du mode : en mode WireGuard, il garde le moteur hors du réseau jusqu'à ce que vous lui donniez un tunnel ou Direct (interface par défaut) (Direct (default interface)) dans sa liste Sortie (Way out) ; en mode Proxy SOCKS5 (SOCKS5 proxy), le proxy hérité est sa sortie, il tourne donc ; en mode Gluetun, un moteur sans interface tourne dans le réseau de gluetun comme les autres ; en mode Proxy SOCKS5 + relais PROXY-v2 (SOCKS5 + PROXY-v2 relay) (et en mode Direct avec kill_switch = true), il n'est bloqué que s'il n'a ni proxy, ni interface, ni direct assumé. Voir VPN & sortie réseau.

À la main : le même bloc, écrit comme un tableau de tables TOML. La table [engine.session] est une surcharge partielle : n'écrivez que ce qui diffère ; toutes les autres clés viennent de [race] ou [hoard] selon le rôle.

[[engine]]
name = "vpn1"
role = "hoard"
engine_id = "vpn1"
  [engine.session]
  listen_port = 16473
  bind_interface = "wg1"

Règles : l'identifiant est engine_id, ou name si engine_id est vide ; un bloc avec un addr est ignoré (il décrit une autre machine, voir Nœuds & plusieurs machines) ; un bloc sans rôle est ignoré sans aucun message ; un bloc dont le rôle n'est ni race ni hoard ne démarre rien et journalise unknown role: this agent starts no engine ; un bloc dont l'identifiant est race ou hoard remplace ce moteur intégré ; une surcharge mal formée est refusée en bloc et la section du rôle ([race] ou [hoard]) est utilisée à la place. Toutes les clés : Config : moteurs & drain race.

Avec Docker, publiez vous-même le nouveau port (16473:16473/tcp et 16473:16473/udp) ; le compose livré ne publie que 16171 et 16172. Ports et redirection de port : Réseau : ports & redirection.

Suppression : Supprimer (Remove) sur la ligne du moteur (non proposé pour race et hoard) demande Remove engine {id}? Its data stays on disk. Un moteur qui tient encore des torrents est refusé (DELETE /api/engines/<id> répond 409 {id} still holds {n} torrent(s): move them to another engine or remove them first) : déplacez-les avec Move to engine › (plus bas) ou supprimez-les d'abord. Pour un moteur vide, son bloc est retiré de default.toml et la page demande un redémarrage ; d'ici là, le moteur continue de tourner avec son listener ouvert, même s'il n'a plus aucun torrent à annoncer ni à seeder. Redémarrer maintenant le ferme.

Depuis la 4.4, un moteur supplémentaire est une identité réseau distincte. Sous Linux, son bind_interface (ou son tunnel WireGuard géré) porte tout ce qu'il envoie : listener, uTP, sa propre file de connexions sortantes, annonces HTTP et UDP, DHT, LSD, webseeds et scrapes, et il fait ses handshakes avec son propre peer id. Son propre max_connections limite ses propres connexions sortantes. Un torrent sur vpn1 est donc vu par les trackers et les pairs avec le peer id et le port de vpn1, à travers wg1. Ce qui reste en dehors (noms de trackers résolus par l'hôte pour une interface qu'Hydranos n'a pas créée, requêtes propres au démon) : VPN & sortie réseau.

Autres limites des moteurs supplémentaires :

• Les cartes Moteur Race / Moteur Hoard de la Vue d'ensemble et la comparaison de Performances (Benchmark) ne montrent que race et hoard ; les moteurs supplémentaires ont leurs propres cartes et courbes, et comptent dans la santé des trackers et dans /metrics (Supervision & journaux).
• Le shim qBittorrent liste tous les moteurs, mais n'ajoute que dans race ou hoard (selon la catégorie) ; voir Shim qBittorrent & automatisation.
• Les moteurs supplémentaires d'un autre nœud ne sont pas affichés sur cette instance ; voir Nœuds & plusieurs machines.

Aucune catégorie ne route vers un moteur supplémentaire : un mode de catégorie ne connaît que race et hoard. Il y a trois façons d'y entrer :

1. Ajouter avec un moteur explicite (API REST native). Le moteur l'emporte sur le mode de la catégorie ; le chemin de sauvegarde vient toujours de la catégorie ou de la requête.

   curl -H "X-Api-Key: YOUR_API_KEY" \
     -F "torrents=@/path/to/file.torrent" \
     -F "category=tv-hoard" \
     -F "engine=vpn1" \
     http://localhost:8199/api/torrents/upload

   Les deux routes d'ajout (celle-ci et la route JSON POST /api/torrents) refusent un moteur inconnu avec un 400 (no engine X).

2. Depuis l'interface web : clic droit sur un torrent (ou une sélection) › Node › Move to engine › ou Duplicate to engine ›, puis choisissez local-<id>. Le groupe Node apparaît dès que cette instance a deux moteurs, donc sur toute installation par défaut. Le moteur où se trouve déjà le torrent n'est pas proposé.

3. Déplacer un torrent existant par l'API REST entre moteurs de cette instance. Utilisez ?engine= pour indiquer quelle copie se déplace quand le torrent est dans plusieurs moteurs.

   curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"engine":"vpn1"}' \
     "http://localhost:8199/api/torrents/0123456789abcdef0123456789abcdef01234567/engine?engine=hoard"

   POST /api/torrents/<hash>/copy avec le même corps correspond à Duplicate to engine.

Move et Duplicate diffèrent par ce que reçoit le moteur cible :

Seul un torrent complet peut être dupliqué : la nouvelle copie se fie aux pièces de la source et ne lit pas les fichiers. Dupliquer sert à seeder un même contenu sous deux identités (deux ports, deux tunnels) ; déplacer sert à changer le moteur, et donc la sortie, depuis lequel un torrent seede.

Les actions groupées agissent sur la copie propre à chaque ligne : Déplacer vers un dossier… (Set location…) et Changer de catégorie + déplacer les fichiers › (Change category + move files ›) sur une ligne local-vpn1 déplacent la copie de vpn1, pas la copie hoard ou race du même hash.

Déplacements entre moteurs et nœuds en tâches groupées : Jobs, actions groupées & déplacement.

Les réglages de moteur vivent dans [race], [hoard] et chaque surcharge [engine.session] (Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) › Session Race / Session Hoard ; l'éditeur ne couvre que race et hoard, modifiez le bloc d'un moteur supplémentaire dans le fichier). La plupart sont lus au démarrage du moteur : redémarrez après les avoir modifiés. Le port d'écoute a un chemin à chaud (voir Réseau : ports & redirection), et les clés de file, de limites de partage, de limites de débit et du choker s'appliquent à chaud, sans redémarrage.

Les clés qui comptent (valeurs par défaut, valeur utilisée quand une clé manque, et chemins à chaud : Config : moteurs & drain race) :

Les clés de file, de limites de partage, de débit et du choker, et start_paused : File d'attente, limites de partage et de débit. Les clés du mode réseau (SOCKS5, proxy d'annonce, PROXY-v2, gluetun, WireGuard, allow_direct) sont écrites par l'onglet Réseau : Réseau : ports & redirection et VPN & sortie réseau.

Piège des valeurs par défaut : quand max_connections manque, il n'y a pas de plafond (le default.toml livré met 4000 et 12000). La DHT, PEX et les webseeds sont actifs quand leur clé manque, comme dans le modèle ; LSD est actif pour race et désactivé pour hoard.

inactivity_timeout et [race.custom_choking] ne sont lus par rien (voir la dernière section). Référence complète des clés : Config : moteurs & drain race.

Variables d'environnement : Config : environnement, CLI & signaux.

active_downloads fixe les emplacements de téléchargement d'un moteur : combien de ses torrents téléchargent en même temps. Toutes les 30 s, le gestionnaire de file démarre les torrents en attente dont l'essaim a le plus de seeders, jusqu'au plafond, et arrête l'excédent ; un torrent arrêté par les emplacements affiche en file (queued) avec En attente d'un créneau (Waiting for a slot) et garde sa progression. 0, négatif ou absent signifie pas de plafond. Les torrents que vous avez arrêtés vous-même ne sont pas touchés.

Dans le default.toml livré, hoard a 10 emplacements et race n'a pas de plafond. Le réglage est par moteur (un moteur supplémentaire hérite de la valeur de son rôle sauf si son bloc en fixe une) et s'applique à chaud : changez-le dans Session Race / Session Hoard, ou avec max_active_downloads du setPreferences de l'API qBittorrent (qui l'écrit dans tous les moteurs locaux). POST/DELETE /api/hoard/download-slots n'existent plus (405) ; le GET reste.

Torrents lents, file de seed (queueing), limites de partage, limites de débit, le choker et un exemple complet (« garder 5 téléchargements actifs ») : File d'attente, limites de partage et de débit.

Accepté mais ignoré en 4.4 : inactivity_timeout (dans le modèle) et [race.custom_choking] (venu de la 3.x) ne sont lus par rien — le délai d'inactivité des pairs est peer_timeout, et le choker est choking = true avec max_uploads_per_torrent ; le démon nomme [race.custom_choking] dans un avertissement au démarrage — laissez-les ou supprimez-les, rien ne change.

Également indisponibles : un réglage du mode de chiffrement, les positions dans la file, et une limite de débit pour tout le client hors de l'API qBittorrent (File d'attente, limites de partage et de débit). HYDRANOS_ENGINE_NET=0 coupe tous les moteurs du réseau, pas un seul (ce qui tourne encore : Réseau : ports & redirection) ; pour retenir un seul moteur au démarrage, utilisez son start_paused.

• Concepts & glossaire — la version courte de cette page.
• Trackers & annonces — rythme des annonces, événements, UDP, peer id.
• Drain race & graduation — ce qui se passe quand un disque race se remplit.
• Config : moteurs & drain race — chaque clé de moteur et sa valeur par défaut.
• File d'attente, limites de partage et de débit — emplacements de téléchargement, limites de partage, limites de débit, choker, pause au démarrage.
• VPN & sortie réseau — ce qui sort par quelle interface.
• WireGuard géré — un tunnel par moteur, monté par Hydranos.
• Réseau : ports & redirection — ports, redirection de port, l'onglet Network.
• Nœuds & plusieurs machines — moteurs sur d'autres machines.
• Supervision & journaux — ce que comptent la Vue d'ensemble et Performances.