BitTorrent is a peer-to-peer file sharing (P2P) protocol facilitating the transfer of files directly between individuals. It differs from client-server methods of filesharing which generally involve transfer of the entire bundle of data (file, webpage, application, etc.) from the computer hosting the data to the recipient of the data. In a client-server transfer, the recipient can only download as fast as the computer hosting the complete file can upload. If three or ten or a hundred people all try to download the file at once, the host must transfer that same data three or ten or a hundred times over.
In contrast BitTorrent allows a file’s recipient to grab lots of small pieces of the bundle, from many different hosts (seeders), as well as from people who are also downloading the file (peers). This reduces the strain on everybody hosting or downloading the file (collectively called the swarm), while hypothetically ensuring that everyone can download at their full download speed. The BitTorrent protocol is the brainchild of programmer Bram Cohen, who designed it in April 2001 and released a first implementation on 2 July 2001. It is now maintained by Cohen’s company BitTorrent, Inc.
The term ‘Tracker‘ has two uses in the world of torrenting. Formally, a BitTorrent tracker is a piece of software that helps individual peers of a torrent to find one another; it keeps tabs on who is seeding a file as well as who wants it, and helps these two groups to connect. The tracker also collects data about who has uploaded how much to whom, how many peers have downloaded (or leeched) a torrent and whether or not they’ve downloaded 100%.
This is a term used in the description of the BitTorrent protocol, and refers to the state of an uploader, i.e. the thread that sends data to another peer. When a connection is choked, it means that the transmitter doesn’t currently want to send anything on that link. A BitTorrent client signals that it’s choked to other clients for a number of reasons, but the most common is that by default a client will only maintain some ‘max_uploads’ number of active simultaneous uploads, the rest will be marked choked. A connection can also be choked for other reasons, for example a peer downloading from a seed will mark his connection as choked since the seed is not interested in receiving anything. Note that since each connection is bidirectional and symmetrical, there are two choked flags for each connection, one for each Tx endpoint.
Rechecking the existing torrent data in a client. When you perform a hash check, your client goes through the process of generating a hash again and checking it against the .torrent file. If you fail a hash check, that’s typically an indication that you have modified something in the file, renamed, or moved the directory. Until you rectify the problem, you will be unable to completely seed the file to other users, and you may have to redownload those sections of the file that failed a hash check.
The hash is the verifying method for checking pieces. In general terms, a hash is any function that converts a large amount of data to a short string that uniquely represents that data. When a user downloads a .torrent file to add to their client, it contains a list of hashes for each bundle. Then, when it begins downloading those bundles of data from other peers, it can generate hashes for the data and ensures the data is bit-for-bit identical to what is listed in the .torrent file. It can then also arrange this into the single, usable file that the downloader expects to receive at the end of the process.
Another term used in the protocol specification. This is the corollary to the choked flag, in that interested refers to the state of a downloader with respect to a connection. A downloader is marked as interested if the other end of the link has any pieces that the client wants, otherwise the connection is marked as not interested.
Synonymous with ‘downloader’, a leech is any peer in the swarm that does not have the entire file. Sometimes also referred to as a peer.
A passkey identifies individual users on private trackers. Each user’s passkey is unique, and it is contained in the announce url in every .torrent file they download from the site. The tracker looks for this passkey and compares it to its database of passkeys before it will distribute the necessary peerlist to that user. The passkey is also how the tracker knows which user to credit upload and download stats to.
Any client inside the swarm, to which other clients can connect and transfer data to or from. Depending on context, ‘peer’ can refer either to any client in the swarm, or more specifically to a leech – a client that has only parts of the file.
The peerlist is how the tracker helps clients to find other clients to download from. It consists of a list of IP addresses that have some or all of the file available to download, from which a user’s client automatically selects some and starts requesting pieces of the file. The peerlist only updates when the client announces to the tracker (roughly every half hour), but if the user is connectable and new peers join the swarm before then, it will see their requests and adds them to the peerlist automatically.
Pieces are how the file is broken in to many, extremely small bundles of data to be distributed to and from numerous peers. Each piece has a corresponding hash in the .torrent metafile, and is verified by a hashcheck after downloading it. Multiple small files (for example, a ripping.log, album.cue, album.m3u, and a release.nfo) can all be assigned to a single piece. If one file in part of the piece is corrupt, the whole piece will need to be redownloaded.
A client that has a complete copy of a certain torrent, and is allowing other clients in the swarm to download from them. This is known as being a seed, or seeding.
The collective group of clients that are connected for a particular torrent. For example, if the tracker returns 10 leeches and 3 seeds, then the swarm consists of you and those 13 other people.
The application you run on your computer or server that handles the interactions necessary for communicating with the tracker and downloading files from others.