Initial-Seeding Leeches

[mike18xx]

First things first: I create and upload new torrent files (which include multiple trackers) on a daily basis, many of them for very large (DVD size or bigger) files -- so I think I know what I think I know when I say it. Anyway, onward then....

Typicial scenerio: 4gigs up & away, super- AKA initial-seeding ON, and I've whapped "update tracker" half a dozen times until all six or seven are lit up, and the peers are out of the gates. Yay me, and fat n' happy everyone else.

Check back in later, and it looks something like this:

BitCometAOL: 25%

swelldude#1: 19%

swelldude#2: 19%

swelldude#3: 19%

swelldude#4: 19%

swelldude#5: 19%

swelldude#6: 18%

swelldude#7: 18%

swelldude#8: 17%

hackleecher: 0.0% (....lists megs uploaded clearly greater than 1%)

The leecher out front plays the routine throttle ULs to 1k game; he's easily recognizable. The hackleecher, however, is more insideous, especially in big torrents where the peer list runs off the bottom of the screen -- he finnagles priority position by continually presenting himself as a "new" peer in need of fresh initial blocks, and he's able to rip off even more than the obvious leeches (because other peers will spot them on there own and eventually kick him with non-uTorrent clients). (Hackleecher reports blazing "Peer dl." speed, too, so he evades the choke-offs uTorrent has in place to prevent 14.4k modems in Kenya from strangling the torrent until their blocks complete.)

Availability: 25.2% ....19.2% after I kick the two leeches with PeerGuardian. Actual uploaded megs represent over 30% of the 4gigs, accounting for the extra amount leeched by the 0.0% hack.

Now I realize that kick/ban is never going to be a part of uTorrent for some pretty sound reasons -- but something really has to be done to thwart initial-seeding leeches, because they can account for between ten and twenty percent of the bandwidth on average.

Recommendations:

* The peer with the largest percentage (if more than one exists) will be denied requests for initial seed blocks.

* peers are denied requests for seed blocks if MB uploaded represents a total greater than listed percentage indicates. If the percentage listed is 0.0%, they are kicked.

[Switeck]

The hackleecher sounds like a BitComet client (or clone). This problem is well-known and documented, and it exploits a hole created by following the bittorrent protocol too literally without oversights. (The hole was new clients were supposed to be 3x as likely to get the 'roaming'/optimistic upload slot until they have something to share. The problem occurs because the BT client fails to recognize reconnecting clients are NOT new clients and the uploader SHOULD know how much the downloader has gotten from him.)

I thought µTorrent prevented this behavior or at least made an effort to fight it.

[pembrokeshire]

It is for this reason that I am unable to ever (so far) use the "initial seeding" option. This is frustrating to me as other torrent software has work arounds for this specific problem. Any ideas would be most welcome.