One program for three kinds of transfer

BitComet is a free download manager that keeps BitTorrent, HTTP and FTP in the same queue. The version described here is 2.22. Putting them together sounds like a small convenience and is actually the reason the program exists: a single file may be reachable by two of those routes at once, and a manager that only knows one of them makes the user choose before knowing which route would have been faster.

The ordinary case is more boring and more common. A project's release notes arrive over HTTP, a large archive arrives over BitTorrent, a mirror inside a company network is only reachable over FTP. One list, one set of limits, one place where progress is visible.

The mechanism behind a swarm

The BitTorrent side of the program follows the protocol rather than inventing around it. A transfer starts from a torrent file or from a magnet link, and the data is exchanged with other participants rather than taken from one server. Everyone in the swarm downloads and uploads at the same time, which is why a popular transfer can be faster than a single server could ever serve it and why an unpopular one can be close to stopped.

That is a description of the mechanics, not an argument about what should be transferred. The protocol is indifferent to content and so is the client; what a swarm can move quickly is a property of how many people are holding it.

The 99 percent problem

The weak point of the design is the end of a transfer. If the only participants holding the missing pieces leave, the download sits at ninety-nine percent and stays there — the file is useless, the space is still occupied, and nothing in the interface explains why.

Long-term seeds address exactly that. Pieces that have been seen once are kept available beyond the lifetime of the peers that happened to hold them, so a transfer that would otherwise stall has somewhere to finish from. The same mechanism usually shows up earlier as speed: a transfer with a long-term source behind it does not have to wait for enough peers to appear at a convenient hour.

Writing through a cache

The disk cache is the least visible feature and the one with the longest consequences. A download is thousands of small writes scattered across a file that is still being assembled; done directly, that pattern keeps a drive busy with seeks and is hard on it. Collecting the pieces in memory and writing them out in larger, ordered batches reduces the number of read and write operations, which is the difference the program is claiming: less wear rather than more speed.

It also explains a behaviour users notice: the last few seconds before a task is reported as finished are sometimes spent writing rather than receiving.

Playing a video that is still arriving

The feature usually called download-and-play depends on one decision: fetch the beginning and the end of a media file first. The beginning is what a player needs to start, and the end holds the index that many containers place there; with both in hand, playback can begin while the middle is still being transferred. Without the tail, a player that insists on reading the index first will refuse to start no matter how much of the middle has arrived.

Where it sits

BitComet is not an open-source project and does not claim to be; it is free, and it is built for people who keep a queue running rather than for people who fetch one file a month. The honest summary is that the three protocol support, the long-term seeds and the download-and-play behaviour are the three features that decide whether it fits: if the work is a mixture of routes and a few large transfers that must not die at ninety-nine percent, this is what the program is for.