Most (but not all) leechers are just cads who choke their uploads. uTorrent is set up to handle them pretty easily during regular seeding or trading, but, if in initial-seeding mode, is exploited by disconnect/reconnect-abusing clients (BitComet, et al). This can add hours if not days to the duration of an initial-seed.

Advice for catching initial-seed leeches:
Code:
* keep an eye on the Peers tab's "Peer dl" column.
* keep an eye on the Peers tab's "Uploaded" column.
* keep an eye on any peer using a client whose name starts with "B".
-- A peer with no number listed in the Peer dl column is likely either completely throttling his uploads, or port-blocked on a "dead-end" node, or is only interested in downloading one file and is just waiting for you to start sending . Such a peer is a less-optimal initial-seeding participant.

-- If your torrent has been initially-seeding for awhile, and some peers have only one piece sent to them in the upload column, then you know their uploads are choked. If you have to stop and start your torrent frequently, such peers will be getting extra blocks each time (and probably not retrading them).

-- If you see a peer continually drop out and reconnect to grab a fresh piece of your initially-seeding torrent, and the "availability" percentage jumps up when they appear and drops when they disappear -- that peer is a leech who's robbing you blind. He's similar to the person described above, but has an "abusive" client.

You can save the IPs of these peers in the Logging tab, then manually enter them in IP-blocking software. (I usually have several categories that I toss these guys into, some perm, some temp.)

My best advice for dealing with leeches is to create torrents with smaller piece sizes. Since most users must configure their clients with a limited number of connections, it will be the preference of the client to drop slower connections for faster ones. This means that a leech with a 4meg piece being released at 1k/sec to six different peers will be constantly dropped by external peers since virtually anyone else will be sending data faster than 0.125k/sec. Clients tend not to prioritize fragmented pieces unless they are ultra-ultra rare (i.e., a torrent in which initial-seeding has been halted until only fragmented pieces remain unshared).

Sometimes, regretably, you have to be a total a-hole in order to shape people up. For example, I have a multi-file torrent recently where a large percentage of the peers were only interested in some of the material. I had difficultly starting the torrent because a lot of people didn't want the first file, and the few who did were slow. So I used regular seeding up to about 10%, then switched over. When the torrent was about 50% completed, I noticed that one leech was still hanging onto about 5% of the torrent. By the time the torrent was at 85%, he still had 4.7% of 6+ gigs of material. This made me very angry, and I "paused" the torrent for a three-day week-end. Either he released his stuff, or it would soon become obvious to scores of people in the torrent who he was, and they would ALL block him permanently.

IMO, dealing with disconnect/reconnect-abusing clients during initial-seeding mode should be a primary focus of forth-coming versions of uTorrent. I think it is imperative that piece re-trading records be maintained across reconnection attempts, and even quit/re-open cycles of uTorrent, until the torrent is fully-seeded.