This is a brief explanation of the anatomy of a BitTorrent session, without going into details on interest, choking, snubbing, et cetera. It's part of my guide to µTorrent's internal tracker, but I didn't want to include it in that article since it was getting a little long, and most readers will already know this info.
Basically, BitTorrent is a way of downloading files which is something of an alternative to HTTP (despite the fact that it uses HTTP). It saves the user a lot of bandwidth because people downloading the file are also uploading it at the same time (or at least making it available for upload).
A BitTorrent session starts on the user's end when that user downloads a
.torrent metadata file. This file contains info about the file you want to download including the tracker address and checksums of each piece.
I'll explain. BitTorrent splits up the payload (the file you want to download using it) into a number of pieces and calculates the checksum of each piece. The checksum is a string of characters (in BitTorrent's case, 160 bits worth as it uses SHA-1) that can be used to verify that the part file you downloaded is exactly the same as what the original creator of the
.torrent had. I won't go into the maths in this, but you can read about it here. This is necessary because when you allow users to upload your files, you want to be sure they're uploading the right thing and not something that could damage your users' computers (eg. viruses).
So that's what the checksums are for. The tracker address is the address of a server that manages a list of the people on the torrent (collectively referred to as a swarm). Typically, if you want to use BitTorrent to distribute data, you'll have to run the tracker yourself so that people can actually get the file. (Although you can use "decentralized tracking" which is a form of DHT, you should always include a tracker too, since DHT isn't supported by all clients, and is still a bit buggy, as well as slower.)