Une nouvelle implémentation de tracker BitTorrent écrite en Elixir

 (github.com/Dahrkael)
2 points par GN⁺ 2025-06-20 | 1 commentaires | Partager sur WhatsApp
  • ExTracker est un tracker BitTorrent développé en Elixir ; il est encore en cours de développement, mais fonctionne déjà, tout en étant explicitement présenté comme n’étant pas encore prêt pour un usage industriel complet
  • Ses objectifs de performance sont les suivants : hautes performances en exploitant tous les cœurs disponibles, fonctionnement basé sur un stockage en mémoire, environ 200 MB de RAM par million de peers, et une architecture exécutable sans configuration séparée
  • Côté BEP liés à BitTorrent, il implémente BEP 0, BEP 15, BEP 23, BEP 7, BEP 21, BEP 24, BEP 41, BEP 48 et BEP 52 ; certains éléments comme les Private Torrents ne sont pas encore implémentés ou ne le sont que partiellement
  • Il prend en charge HTTPS, la sauvegarde de la base de données sur disque et l’exécution via Docker ; WebTorrent n’est pas pris en charge, tandis que la whitelist/blacklist, la gestion des peers, les metrics et GeoIP sont en implémentation partielle
  • Il existe trois modes d’exécution : directement depuis les sources, via un build de release manuel, ou via une image Docker ; dans un conteneur, la configuration peut se faire par variables d’environnement au lieu de runtime.exs

État et objectifs d’ExTracker

  • ExTracker est une implémentation de tracker BitTorrent présentée comme « The Bittorrent Tracker made in Elixir »
  • Le projet est en état de Work In Progress
    • Il est explicitement indiqué qu’il n’est pas encore prêt pour un usage industriel complet
    • Il est néanmoins déjà fonctionnel
  • Une instance de test est en cours d’exécution sur extracker.dahrkael.net:6969, avec les fonctionnalités actuelles activées

Fonctionnalités principales

  • Les performances et la simplicité d’exploitation sont mises en avant comme fonctionnalités clés
    • Hautes performances : exploite tous les cœurs disponibles
    • Utilise un stockage en mémoire
    • La consommation mémoire est d’environ 200 MB de RAM pour 1 million de peers
    • Zero setup : l’objectif est de fonctionner immédiatement au lancement

État du support des BEP BitTorrent

Autres fonctionnalités et limitations

  • Fonctionnalités terminées

    • Prise en charge de HTTPS

      • Sauvegarde de la base de données sur disque
      • Fonctionnalités non prises en charge
      • WebTorrent
      • Fonctionnalités partiellement implémentées

    • Whitelist/blacklist d’infohash

      • gestion des peers : interval enforcement, cleanup, banning, etc.

    • Metrics

      • Prise en charge de GeoIP : pour les statistiques et les restrictions sur les peers
      • Les propositions de fonctionnalités peuvent être soumises via les Issues

Méthodes d’exécution

  • Exécution directe depuis le code source

  • Build de release

    • Il n’existe actuellement pas de build de release officiel, mais il est possible de créer et distribuer soi-même une release
    • Cloner le dépôt puis compiler selon le système d’exploitation visé
    • Linux : MIX_ENV=prod mix release extracker
    • Windows : MIX_ENV=prod mix release extrackerw
    • Les fichiers de release sont générés dans le dossier _build/prod/rel/extracker
    • En cas de transfert vers une autre machine, l’OS et l’architecture doivent être identiques
    • Modifier la configuration releases/{VERSION}/runtime.exs si nécessaire
    • La commande d’exécution est bin/extracker start

  • Exécution avec Docker

    • L’image Docker fournie peut être exécutée directement
    • docker run ghcr.io/dahrkael/extracker:latest
    • Une utilisation avec docker-compose est également possible, avec un fichier compose d’exemple
    • Comme il est difficile d’ajuster la configuration en modifiant runtime.exs à l’intérieur du conteneur, la configuration peut aussi se faire via des variables d’environnement
    • La liste complète des variables d’environnement est disponible dans le fichier compose d’exemple

Licence

  • ExTracker est distribué sous les termes de la Apache License 2.0
  • Pour plus de détails, voir le fichier LICENSE du dépôt

À lire aussi

1 commentaires

 
GN⁺ 2025-06-20
Avis sur Hacker News

  • Je m’attendais à une conception pensée d’abord pour OTP, mais le code touche directement ETS, ou une Application basée sur ETS, pour presque toutes les opérations, ce qui le fait plutôt ressembler à du procédural ; c’est dommage.
    Pour apprendre à concevoir des services avec OTP en Elixir ou dans un autre langage BEAM, les livres "Designing Elixir Systems with OTP" de James Edward Gray et Bruce Tate, et "Functional Web Development with Elixir, OTP, and Phoenix" de Lance Halvorsen sont de bonnes références.

    • Lors de ma première tentative, je l’avais écrit d’une manière plus OTP-esque, mais dans ce flux précis, l’extensibilité n’était pas équivalente.
      Au final, un tracker torrent ressemble davantage à une base de données spécialisée, et l’objectif prioritaire est de traiter les données le plus vite possible.
      Je lirai quand même ces livres.
    • Si vous ne savez pas ce qu’est OTP dans ce contexte, OTP signifie Open Telecom Platform.
      Aujourd’hui, cela s’applique moins aux télécommunications elles-mêmes qu’aux logiciels ayant les caractéristiques d’applications de communication ; si la moitié de la grandeur d’Erlang vient de sa concurrence et de sa distribution, et l’autre moitié de sa capacité à gérer les erreurs, alors le framework OTP peut être vu comme cette « troisième moitié ».
      https://learnyousomeerlang.com/what-is-otp
    • Construire un tracker BitTorrent avec des GenServer, ça n’a aucun sens.
      Pour une configuration à serveur unique, ETS est à 100 % le bon choix, et même si ça ne permettra pas de scale horizontalement, le scale vertical devrait être excellent.
      De toute façon, la plupart du temps, c’est probablement du YAGNI.
    • Une grande partie des atouts d’Elixir et d’Erlang tient au fait qu’on peut écrire du code très intuitif tout en obtenant de bonnes performances.
      Il y a sûrement des cas où des GenServer supplémentaires ou gen_statem s’intègrent élégamment, mais pour beaucoup d’usages d’Elixir et de Phoenix, il n’est pas nécessaire de faire des choix d’architecture sophistiqués.
      Le runtime fait déjà suffisamment de choses sophistiquées à votre place.
    • Je suis curieux : à quoi devrait ressembler une conception pensée d’abord pour OTP ?
      ETS est intégré à OTP, donc je ne vois pas pourquoi utiliser ETS ne serait pas « OTP-first ».
      Je ne vois pas non plus vraiment le problème avec ETS : ce n’est qu’un stockage en mémoire.
      J’ai parcouru le code, et je n’ai pas eu l’impression qu’il soit particulièrement procédural.

  • Beau travail. Ce serait bien de passer de IO.puts à Logger, et d’envisager aussi l’ajout d’OTel.

  • J’adore vraiment Elixir. Je construis en ce moment un superbe moteur de notifications en Elixir, et c’est vraiment excellent.

    • Ça a l’air sympa. Je me demande s’il est privé ou open source.
      Elixir a vraiment besoin d’un meilleur moteur de notifications.

  • Félicitations pour le lancement. Je serais curieux d’avoir plus de détails sur son comportement par rapport à opentracker.
    Les aspects comme les performances m’intéressent beaucoup.

    • Pour un petit tracker, opentracker sera probablement plus rapide et consommera un peu moins de mémoire.
      Là où ExTracker brille, c’est quand le nombre de cœurs commence à atteindre deux chiffres.
      Cela dit, il reste encore à faire de vrais benchmarks.

  • Ça a l’air bien. J’irai voir ça plus tard.
    Il y a quelques années, j’avais créé un tracker basique en Elixir ; le code est ici : https://github.com/aalin/mr_torrent

    • Intéressant. Je me demande pourquoi vous avez décidé d’en faire spécifiquement un tracker privé.

  • Intéressant. Pour en apprendre davantage sur BitTorrent, j’ai construit quelque chose de similaire en TypeScript, puis je l’ai refait en Rust pour apprendre Rust : https://github.com/ckcr4lyf/kiryuu
    De mon côté, j’ai simplement utilisé Redis comme base de données. Ce projet semble avoir toute la base de données en mémoire ; je serais curieux de savoir s’il y a eu des décisions de conception intéressantes ou des problèmes rencontrés avec cette approche.
    Ma solution avec Redis n’est pas très bonne, je crois, car elle ne randomise pas les pairs lors des announce suivants.

    • Dans mon cas, utiliser ETS en mémoire a été la meilleure décision.
      Les données de chaque pair peuvent être lues et écrites simultanément par leurs propres processus, ce qui minimise la contention et la latence.
      La seule partie traitée séquentiellement est la création initiale d’un nouveau swarm, mais cela n’arrive pas souvent, donc ce n’est pas gênant.
      Malheureusement, il n’y a pas de prise en charge native pour récupérer directement une ligne aléatoire dans une table ; pour l’instant, je récupère donc tout le swarm puis je choisis un sous-ensemble aléatoire : https://github.com/Dahrkael/ExTracker/blob/master/lib/ex_tra...

  • Ce serait bien d’expliquer ce que sont DHT et PEX. Il est difficile de chercher "tracker PEX".

  • Super. Je me demande si tu aimerais utiliser Elixir comme activité principale.

    • Je ne suis pas l’auteur du post, mais je travaille avec Elixir depuis 9 ans et 2 mois.
      Je connais aussi Rust et Go. Vous recrutez ?
    • C’est l’une des options, oui. Je pense que j’y prendrais beaucoup plus de plaisir qu’avec C++.

  • Je serais curieux de savoir comment ça a commencé, si tu t’es inspiré d’autres projets, combien de temps ça a pris, et dans quelle mesure tu estimes que les fonctionnalités marchent par rapport à quelque chose comme qBittorrent.

    • J’ai commencé parce qu’un autre projet avait besoin d’un tracker, puis construire le tracker est devenu la partie la plus amusante.
      J’ai aussi parcouru le code d’autres trackers, mais ils étaient pour la plupart soit excessivement complexes, soit trop simples, donc ils ne m’ont pas vraiment aidé.
      Jusqu’ici, c’est le résultat de 3 mois de retardement du coucher par procrastination de vengeance.
      Ce n’est pas un client comme qBittorrent, mais j’ai des idées pour un futur projet de client orienté seedbox.
    • C’est un tracker, pas un client torrent.

  • Je l’ai essayé, mais je n’ai pas réussi à faire fonctionner HTTPS.
    Dans la console, 04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused" s’affiche en boucle, mais ça semble fonctionner.
    J’aurais aussi aimé voir les statistiques HTTP, même si UDP me va aussi. Cela dit, j’ai désactivé UDP de mon côté.

    • L’événement "paused" fait partie de BEP 21.
      Il est envoyé quand le client informe le tracker qu’il n’est pas encore en état terminé, mais qu’il ne téléchargera plus.
      Par exemple, lorsque l’utilisateur ne veut qu’une partie des fichiers du torrent.
      D’après le README du projet, la prise en charge de BEP 21 n’est pas implémentée.
    • La Telemetry côté HTTP est dans la liste des choses à faire.
      Comme j’utilise une bibliothèque tierce pour le serveur web, je dois encore trouver la bonne façon de procéder.
      Pour utiliser HTTPS, il faut fournir à :https_keyfile un chemin vers un certificat valide, mais pour l’instant, si HTTPS est nécessaire, je recommande de mettre Caddy ou Nginx devant le tracker.
      L’intégration de certbot est également prévue, mais comme la plupart des pairs torrent utilisent UDP, ce n’est pas une priorité élevée.