libtorrent: a C++ BitTorrent engine you build with b2

A library for software that transfers, not a client for people who download

libtorrent implements the BitTorrent protocol in C++, along with most popular extensions, and positions itself for real world deployment. It is a library: you link it into software that moves files, rather than installing it to download anything yourself. Configuration is a stated design axis, with the README describing it as configurable to fit both servers and embedded devices, and the main goals are efficiency and ease of use. The runtime question is real when choosing: a Go service can get the same job done with anacrolix/torrent, a Go BitTorrent library, and the honest comparison is ecosystem and runtime fit rather than a feature list. If your project is C++, this is the implementation whose internals you can read, fuzz and simulate from one repository.

b2 in the root, and a Makefile that remembers the flags

Building goes through boost-build. With boost and boost-build installed, run b2 in the repository root, and run b2 again inside examples to build the sample programs. The Makefile exists so you do not have to remember the invocation:

BUILD_CONFIG=release link=shared crypto=openssl warnings=off address-model=64

That line is the default configuration the Makefile passes to b2, folding in CXXFLAGS and LDFLAGS from the environment when they are set. Named targets wrap the same call: install honors a PREFIX that defaults to /usr/local/, python-binding works inside bindings/python with stage_module stage_dependencies, and examples stages client_test and connection_tester. One nuance worth knowing: the sim target filters crypto=openssl back out and builds the simulation tree with crypto=built-in instead.

RC_2_1 is the default branch, and two series ship in parallel

Repository habits here differ from most projects. The default branch is RC_2_1, a release-candidate name rather than main or master, and release tags come in two parallel series: v2.1.2 and v2.0.15 were both tagged on 2026-09-25, and v2.1.1 arrived on 2026-08-10. The last push was on 2026-09-29. The codecov badge in the README is pinned to RC_2_0, a third branch name, so coverage and development are tracked on different lines at once. For anyone packaging or pinning, the series choice is a real decision, and the repository gives you three places to check what moved: ChangeLog, NEWS, and the ABI report linked from the README for binary compatibility history.

Python bindings arrive through a cibuildwheel maze

Python support is deep enough to carry its own CI badge and a pyproject.toml declaring name libtorrent, version 2.1.2 and requires-python >=3.9. The root setup.py is a shim that changes into bindings/python and runs the setup.py living there. Wheel building is scripted with cibuildwheel, and the matrix shows the real cost: manylinux2014 images, pp* and cp311-* skipped, Boost 1.83.0 installed to /tmp/boost by a setup script, OpenSSL from brew on macOS, and on Linux glibc-static installed with yum because libutil.a and libdl.a are needed, ccache warmed before tests, plus a separate musl track using apk to add ccache, openssl-dev and openssl-libs-static. Test commands run pytest and mypy against the bindings, with mypy configured from mypy-tox.ini.

examples/ is the tutorial the README never wrote

The README says almost nothing about usage, deferring to libtorrent.org, but the examples directory works as a syllabus. bt-get, bt-get2 and bt-get3 are three generations of a minimal downloader. simple_client.cpp and client_test.cpp grow from there, with connection_tester staged alongside for testing connections. make_torrent.cpp creates torrents, magnet2torrent.cpp and torrent2magnet.cpp convert in both directions between magnet links and torrent files, dht_scrape.cpp works with the DHT, and custom_storage.cpp shows overriding storage behavior. check_files.cpp, rename_torrents.cpp, dump_torrent.cpp and stats_counters.cpp cover verification, renaming, inspection and counters, while run_benchmarks.py drives performance runs. Building all of it is the documented b2 command run inside the examples directory.

Fuzzing, simulations and tidy files

Engineering hygiene is visible rather than claimed. GitHub Actions workflows cover windows, macos, linux and python. An oss-fuzz badge links to the project's issue list on the fuzzer's own site, which means continuous fuzzing is outsourced and public. Static analysis leaves fingerprints: .clang-format, .clang-tidy, .cppcheck-suppressions and .asan.suppressions files sit at the repository root. A simulation directory builds network simulations with the crypto backend swapped to built-in, per the Makefile's sim target, and test/ carries the suite that the check target builds. A .claude/ directory also sits in the tree. OpenHub and a CII best practices badge round out the external self-reporting.

NOASSERTION: the licence GitHub will not name

Both COPYING and LICENSE files exist in the repository, yet GitHub reports the licence as NOASSERTION, meaning no recognized licence was auto-detected. Anyone embedding libtorrent in shipped software reads those files directly instead of trusting a badge, and the licence review stays with the adopting team. Distribution watchers get one more rename to track: repology follows the package across Linux distributions under the name libtorrent-rasterbar, which is why some system documentation calls it that instead of libtorrent. Documentation itself lives on libtorrent.org, with building.rst for build options and python_binding.rst for the Python side, and the ABI report tracks binary compatibility over time. Version 2.1.2 is current, tagged 2026-09-25.

Editorial conclusion

Adopt libtorrent when you are writing software that needs BitTorrent transfer in process, on servers or embedded devices, and C++ fits your stack. Choose a finished client application for one-off downloading, and a Go library such as anacrolix/torrent when your service already lives in Go. Verify first what licence actually applies: GitHub marks the repository NOASSERTION even though COPYING and LICENSE files are present, so those files are the only authority, and confirm which release series, v2.0.x or v2.1.x, your packager targets.

Frequently asked questions

Official sources

1. arvidn/libtorrent on GitHub
2. Issues
3. Project website
4. README
5. Releases