From the engine room: Moving to opentracker

by Michael Tremer, December 4, 2017

Do you like what you are reading? Subscribe to our newsletter and don't miss out on the latest...   Join Now

We host our own infrastructure here and use multiple mirror servers to cope with the amount of downloads and also to provide good redundancy. After all it is not too bad to host this project from the bandwidth’s perspective since most people update anyway and for our new users, the OS image is not too large. It only has about ~150-200MB depending on the image you are downloading.

However, we still provide torrent downloads which are useful for people who cannot reach our website which unfortunately seems to be blocked in some countries. Just getting the magnet URL is enough to download it.

They are also useful because we do not have to provide 100% of the bandwidth and they also check the integrity of the downloaded file.

What is a tracker?

To provide communication between the multiple peers that want to download a torrent file and the seeders who have some parts of the file or the entire file ready to be uploaded again, a database called the tracker is being used. It just exchanges IP addresses and the peers spin up a peer-to-peer network and transfer the data directly.

That tracker was implemented in our webapp that is hosting the website, this blog, fireinfo and some more things, but it was not really the best implementation there is. It was stable, it was good, but it was not too efficient by using a PostgreSQL backend and unfortunately had some bugs when it came to peers with IPv6 access as well as IPv4 access.

opentracker

So to make our infrastructure leaner, faster and generally better, I installed opentracker which we used to use in the past before we wrote our own implementation. Since then it has grown a bit and is now available in repositories of CentOS which we use on many of our servers. Hence I installed it quickly, configured it and did the switch. For a few weeks now, the torrent tracker has been running on opentracker and it just works.

The tracker part of the webapp has been removed which takes quite a load off of it and we switched from an open tracker to a closed one which will only accept our own torrent files. On top of the HTTP protocol, we also support contacting the tracker over UDP and we are running two instances of opentracker; one for IPv4 and one for IPv6.

Next time maybe, you might want to use the torrent network to download a disk image of IPFire. I still find it a very fascinating way to exchange data and although people instantly think about sharing the wrong things, the torrent network is used a lot to distribute files like this and even commercial vendors of games and similar large files use it.