The engines underneath

It is not something you run and not something with a window: it is the code that does the announcing, the peer finding, the choking, the piece picking, the hashing and the encryption, sitting underneath an interface that somebody else wrote. qBittorrent and Deluge are both interfaces over libtorrent, which is why two programs that look nothing alike behave almost identically once a transfer starts.

What libtorrent does that the client above it does not

libtorrent does the protocol, and the client above it does the presentation and the policy. Split the work and the division is clean. The library parses the torrent file and the magnet link, opens the listening socket, announces to trackers, runs the distributed hash table, exchanges peer lists, negotiates protocol encryption, decides which piece to request next, verifies each finished piece against its SHA-1 hash and writes it to disk. The client decides what the list looks like, which of those knobs it exposes, where files are saved, what a category means and whether there is a web interface.

That is why a client release note can say the engine was updated and nothing visible changes: the behavior on the wire moved, and the window did not.

The two different libraries called libtorrent

Two unrelated libraries carry this name, and confusing them wastes a great deal of reading time. The one qBittorrent and Deluge use is properly libtorrent-rasterbar, after the Rasterbar project that publishes it, written in C++ and hosted with its source and its releases on GitHub. The other is libTorrent, a separate C++ implementation written for the rTorrent client, with its own code, its own maintainers and no shared history with the first.

When a comparison, a package name or a forum answer says libtorrent without qualification, it almost always means libtorrent-rasterbar, and the rest of this page does too.

Which clients sit on libtorrent, and what they inherit

Two of the three clients covered here sit on libtorrent, and the third does not.

What the first two inherit is everything at protocol level: the same distributed hash table implementation, the same peer exchange, the same local peer discovery, the same protocol encryption negotiation, the same microtransport protocol for keeping a transfer from saturating a line, and the same rarest first piece picker. What they do not inherit is defaults. qBittorrent and Deluge can ship different connection limits, different cache behavior and different queueing over identical engine code, and those differences are real even though the protocol behavior is not.

The distributed hash table, the part of libtorrent people meet by name

The distributed hash table is the piece of the engine most people meet under an abbreviation, usually as DHT in a client's status bar. It is a Kademlia style network in which every participating client stores a slice of a shared index mapping info hashes to the peers holding them, so a client can ask the network which peers have a torrent without asking any tracker at all. That is what lets a magnet link work with no tracker in it.

One implementation, called Mainline DHT, is what almost everything speaks: libtorrent implements it, and so do uTorrent and the mainline BitTorrent client, which is why clients from unrelated projects find each other in the same table. Vuze historically ran a second, incompatible table of its own alongside it, and peers found there were not visible to everybody else. Finding peers covers the wider set of discovery methods; the point here is that DHT is engine code, not client code, so a client cannot be better at it than the library it uses.

libtorrent and uTorrent are not the same kind of thing

libtorrent is a library and uTorrent is a finished program, so comparing them directly is a category error, but the comparison has a real answer underneath it. uTorrent does not use libtorrent. It is closed source, made by a company, and carries its own engine, which nobody outside that company can read or reuse.

The traffic runs the other way too. The microtransport protocol, which throttles a transfer when it detects the line filling so that browsing stays responsive, originated in uTorrent and was published as an open specification. libtorrent implements it, and so does libtransmission, which is why a modern client of any make behaves politely on a shared connection.

Installing libtorrent, and why you almost certainly do not need to

Installing libtorrent by hand is unnecessary for anyone who simply wants to run a client, because every client that uses it ships it. On Windows and macOS the library is compiled into the installer you already downloaded. On Linux the distribution packages it separately, so an apt or dnf install of qBittorrent or Deluge pulls in the library package, and Deluge additionally needs the Python bindings package, which the distribution names accordingly.

Installing it deliberately is a developer task. The source is on GitHub, the build uses CMake, it depends on Boost, and on Windows the usual route is a package manager for C++ dependencies rather than a hand assembled toolchain. If your reason for wanting it is that a client is behaving oddly, the engine is not the place to start, and qBittorrent is the page that covers what the client itself controls.

What all this means when you read a client comparison

Reading a client comparison is much easier once you know which engine each program carries. Three rules fall straight out of it. A speed claim between two libtorrent clients is a claim about defaults, disk handling or the interface, never about the protocol. A protocol feature described as belonging to a client, such as DHT, peer exchange or protocol encryption, usually belongs to the engine and arrives in every client sharing it. And a genuine engine difference, as between qBittorrent and Transmission, shows up as footprint and platform reach rather than as throughput. How a transfer works and The swarm cover what the engine is doing while all of that is being argued about.