←back to thread

Show HN: I wrote a new BitTorrent tracker in Elixir

(github.com)
394 points dahrkael | 3 comments | 19 Jun 25 22:49 UTC | HN request time: 1.139s | source

Hello everyone!

I'm currently in a journey to learn and improve my Elixir and Go skills (my daily job uses C++) and looking through my backlog for projects to take on I decided Elixir is the perfect language to write a highly-parallel BitTorrent tracker. So I have spent my free time these last 3 months writing one! Now I think it has enough features to present it to the world (and a docker image to give it a quick try).

I know some people see trackers as relics of the past now that DHT and PEX are common but I think they still serve a purpose in today's Internet (purely talking about public trackers). That said there is not a lot going on in terms of new developments since everyone just throws opentracker in a vps a calls it a day (honorable exceptions: aquatic and torrust).

I plan to continue development for the foreseeable future and add some (optional) esoteric features along the way so if anyone currently operates a tracker please give a try and enjoy the lack of crashes.

note: only swarm_printout.ex has been vibe coded, the rest has all been written by hand.

1. arch-choot ◴[20 Jun 25 07:27 UTC] No.44325462[source]▶
Interesting! I'd done something similar in Typescript to learn more about BT, and then redid it in rust to learn rust (https://github.com/ckcr4lyf/kiryuu).

However I decided to just use redis as the DB. It sounds like your entire DB is in memory? Any interesting design decisions you made and/or problems faced in doing so?

(My redis solution isn't great since it does not randomize peers in subsequent announces afaik)

replies(1): >>44325659 #
2. dahrkael ◴[20 Jun 25 08:17 UTC] No.44325659[source]▶
in my case using the in-memory ETS has been the best decision, it lets me read&write the peer's data concurrently each on its own process so contention and latency are minimal. the only sequential part is when a new swarm is initially created but that doesn't happen a lot so its fine. there's sadly no native support for taking random rows directly from the tables, so for now i grab the whole swarm and then take a random subset (https://github.com/Dahrkael/ExTracker/blob/master/lib/ex_tra...)
replies(1): >>44330601 #
3. toast0 ◴[20 Jun 25 18:36 UTC] No.44330601[source]▶
I don't remember if there's a way to see how many slots an ets table has, but if you're ok with imperfect distribution, you could maybe pick a slot at random and use ets:slot/2 to get all the items in that slot, then select from those.

You might be able to get the slot count from eta:table_info(Table, stats), although that's not intended for production use, so the format may change without notice.