MonoTorrent: a BitTorrent protocol library for .NET

A protocol library rather than a torrent client

MonoTorrent is the official repository for a BitTorrent library for .NET, written in C# and published on NuGet under the MonoTorrent package name, with badges for the stable version and the pre-release version side by side. The README describes a client that downloads torrents and has a wide range of functionality, but the deliverable is the library itself: there is no application, no GUI and no command line tool described anywhere in the project.

That makes the audience specific. If you are writing a desktop client, a media server component, a seed box panel or a dataset fetcher in C#, the protocol work is what you would otherwise spend months on, and MonoTorrent has been doing it for years under an MIT licence. If you wanted an application to download something, this is the wrong repository.

The project is hosted by alanmcgovern, with the repository at github.com/alanmcgovern/monotorrent. It is funded through Open Collective, which the README links for both individual and organisational contributions, and it acknowledges JetBrains for supplying a free licence for its tooling, specifically dotTrace for performance profiling and dotMemory for memory allocation and retention profiling.

Which BEPs the implementation actually covers

The README keeps a running list of the BitTorrent Enhancement Proposals that have been implemented, split into three groups, and that list is the honest summary of the protocol surface.

Two specifications are final and active: BEP 3, the BitTorrent protocol specification itself, and BEP 20 for peer ID conventions. Twelve more are accepted, covering the DHT protocol (BEP 5), the fast extension (BEP 6), the IPv6 tracker extension (BEP 7), metadata exchange (BEP 9), the extension protocol (BEP 10), peer exchange (BEP 11), multitracker metadata (BEP 12), local service and peer discovery (BEP 14), the UDP tracker protocol (BEP 15), HTTP, FTP and web seeding (BEP 19), compact peer lists from trackers (BEP 23) and private torrents (BEP 27).

Four sit in draft: superseeding (BEP 16), the tracker protocol scrape extension (BEP 48), padding files and extended file attributes (BEP 47) and the BitTorrent protocol specification v2 (BEP 52). Message stream encryption as used by Vuze is listed separately as an additional scheme rather than a BEP.

For an engineer, that split is the useful part. Everything needed to join a modern swarm is accepted, while the features that change the wire format in incompatible ways remain draft, which is where you would expect a conservative library to sit.

Piece picking, sequential download and the end-game mode

The client feature list describes scheduling behaviour in some detail, which is where a BitTorrent implementation is usually judged.

Piece selection is rarest first, and the README notes that the prioritisation takes that into account, so a file you asked for can pull pieces that no other peer has. On top of that sit per-file prioritisation, selective download including the explicit ability to skip specific files, and sequential downloading for media files, where the piece order follows playback order instead of rarity. There is also an end-game mode to boost the last one or two percent of a download, the phase where the slowest pieces normally hold everything up.

Two rate controls sit alongside those choices: per-torrent download and upload limits, and overall limits across all torrents. The end-game mode and the sequential option are the two features most likely to matter to a specific application, and both are in the library rather than something you have to bolt on.

Disk behaviour: caching, auto-throttling and incremental hashing

The disk side of the list is where a library earns its place, because these are the parts every client reimplements badly.

There is an in-memory cache to reduce disk reads, and an auto-throttling behaviour that slows the download when the download rate exceeds the rate at which pieces can be verified and written to disk. That second feature is the one that prevents a fast connection from producing a stalled transfer.

Hashing is handled in three distinct ways. Fast resume data can be saved and restored, which avoids hashing the data every time a torrent starts. Incremental piece hashing reduces disk reads by hashing each block in a piece as it arrives. Partial hash checking means that if a TorrentFile has its Priority set to DoNotDownload, those files are skipped when the hash check runs, and if the priority is later raised, the files are hash checked automatically before any piece of them is downloaded.

That last behaviour is a small design decision with real consequences for a media application, where a season of files is present but only some are wanted. Sparse files on NTFS are also supported, which matters for the same use case, since a partially downloaded file does not have to occupy the space of the full one.

Tracker support and the port forwarding path

The README also describes tracker behaviour, which is what makes the library useful on the other side of a swarm. HTTP announce and scrape requests are supported, as are UDP announce and scrape requests, and compact peer responses are used to reduce bandwidth. A tracker can optionally allow unregistered torrents, in which mode it begins maintaining peer lists for a torrent as soon as the first announce request arrives.

On the client side, magnet URIs can be created and used, and port forwarding is handled through UPnP and NAT-PMP with the Mono.Nat library. Peer address ban lists and both IPv4 and IPv6 connections are in the feature list.

The Mono.Nat dependency is the part to check for a deployment. Automatic port mapping needs a router that supports one of those two protocols, and on a locked-down network the client will simply fail to accept incoming connections and rely on outbound connections and peer exchange instead. That is normal for BitTorrent clients, but it changes the throughput you should expect from a seed box in a data centre.

Building and packing the nupkg on Windows

The build is a Windows toolchain driven by MSBuild, and the Makefile at the root of the repository shows the three targets available. The default target builds the solution, clean runs the Clean target, and pack produces the NuGet package in Release configuration:

pack:
    @echo Creating the nupkg
    $(XBUILD) $(XBUILD_ARGS) /t:Pack /p:Configuration=Release

The variables behind it are msbuild and the argument /nologo /restore, so a target expands to a restore-and-pack invocation. On Windows the same job is available as a script, with pack.bat for packaging, coverage.bat for coverage output, and azure-pipelines.yml holding the pipeline definition that the build, test status and code coverage badges in the README point at.

The rest of the tree shows where the work sits: src/ for the code, docs/ for the documentation, build.proj for the project structure, version.txt and alpha.txt for release metadata, and a Makefile that assumes a Windows shell with make installed, since the repository is built on the maintainer's own machine rather than in a container.

Release naming and the state of the project

The release tags are the first thing to look at when adopting this. The three most recent are release-v3.9.0-alpha-0000 from 2026-06-14, release-v3.0.3-beta-0049 from 2024-09-14 and release-v3.0.3-beta-0024 from 2024-08-28. The pattern is a build number appended to a pre-release suffix, which tells you two things: the versioning is designed for frequent automated publishing, and the most recent tagged releases are pre-release versions.

The last push to the repository was on 2026-07-31, so the code is moving, and the project is not archived. The MIT licence keeps it usable inside proprietary products without obligations beyond attribution, and the Open Collective funding model means contributions of both code and money are handled through the same repository.

The practical caution is version choice rather than health. Pinning to a stable NuGet release means an older but tested code base, while the alpha line carries recent protocol work and the fixes that come with it. The README does not publish a support matrix or a migration guide for the alpha stream, so an adopter is choosing based on the release notes.

Editorial conclusion

MonoTorrent suits a team building a torrent client, a seeding box application or a research tool in C# who wants protocol handling rather than a finished program. It is the wrong choice if you need a user interface or a stable release, since the repository publishes tags such as v3.9.0-alpha-0000 and the last push was on 2026-07-31. Verify first that the NuGet version you pick matches the target framework of your application, that the peer exchange and UDP tracker paths behave on the network you deploy to, and that the port forwarding path through Mono.Nat works on the NAT your users sit behind.

Frequently asked questions

Official sources

1. alanmcgovern/monotorrent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases