Architecture FR

🇬🇧 English · 🇫🇷 Français

Architecture

                ┌──────────── hydra (process Go) ─────────────┐
  navigateur ───┤  front (contrôle) : UI web (SSE), REST /api/*│
  *arr/autobrr ─┤  shim qBit /api/v2/*, routage, agrégation    │
                │  agent (données) : annonces + persistance     │
                └───────────────┬────────────────────┬────────┘
                                │ JSON-RPC local     │ gRPC (agent distant)
                        ┌───────┴───────┐    ┌───────┴───────┐
                        │ Typhon (Rust) │    │ Typhon (Rust) │
                        │  moteur race  │    │  moteur hoard │
                        └───────────────┘    └───────────────┘

• Plan de contrôle / front (internal/api) : UI web (SSE), REST /api/*, le shim qBit /api/v2/*, le routage/placement par catégorie et l'agrégation multi-agent. Il n'annonce jamais ; un nœud --front-only n'a pas de moteur.
• Plan de données / agent (internal/engine + Typhon) : le moteur torrent plus le scheduler d'annonce et la persistance durable. Chaque agent annonce ses propres moteurs avec sa propre IP/egress. Dans le monolithe, front et agent vivent dans un seul process ; sépare-les avec --agent-only / --front-only (Topologies de déploiement).
• Typhon (typhon-engine/, Rust) est le cœur BitTorrent : protocole peer, sélection de pièces, I/O disque, choking. Un process par moteur, piloté via un JSON-RPC sur socket Unix (ou gRPC vers un agent distant, TLS + token).

Pourquoi deux moteurs ?

race et hoard sont le même cœur réglé pour des jobs opposés : race est agressif et éphémère (choper une release chaude vite), hoard est optimisé upload et longue durée (seeder des dizaines de milliers de torrents à moindre coût). Ce sont des process séparés avec ports, resume et stores durables distincts, donc l'un ne peut pas bloquer l'autre. Tu peux aussi ajouter des moteurs et sharder.

Persistance

Chaque moteur possède un store durable SQLite à côté de ses resume. Les ajouts sont durables immédiatement (une ligne), donc un crash avant le prochain flush périodique ne perd pas de torrents, et les blobs .torrent content-addressés font qu'un re-add ne peut pas entrer en collision par nom de fichier. Au boot le moteur recharge depuis resume + store plutôt que de re-hasher le disque.

Voir docs/ pour la référence API (API.md) et les notes agent/front.