Initial-seeding leech-thwarting by availability percentage tracking

[Honeyfrog]

This is very simple: In initial-seeding mode, if the torrent's availability percentage jumps when a peer connects, then he will NOT be sent a piece.

(This will beat the BitComet disconnect/reconnect game on the head with a shovel. "Down boy! Down!" ...and it won't matter if they've hacked the client to report itself as something else, or increased their disconnect time to evade any present tracking scheme used by uTorrent. Neither will revolving their IP-address....they simply can't hide the fact that they have too many unique pieces.)

[Switeck]

Many cheating clients that regularly reconnect report themselves as 0% complete.

"Hey, I'm a brand new peer -- send me something so I have something to upload!"

[Honeyfrog]

I thought the 0.0 cases were already handled ages ago -- ?

If not, suggestion: Send them 16k of the next piece....and if they then report a percentage, disconnect them and reset the "next piece up" counter. -- It's time to forcibly obsolesce those older BitComet versions and hacked clones.

--//--

I'm tired of waking up to find cheating peers bouncing in and out and having swiped 25% of my initial-seed overnight, with the availability percentage swinging wildly every time they cycle. I can manually block-list 'em all day long, but there's always a fresh horde of lampreys attached to my torrent again in the morning.

Please build something in to kill these supergigantic a-holes. Seeding an extra 25% of 700mb is annoying; seeding 25% more of 4gb is maddening; seeding 25% more of 20gb is totally intolerable.

I've been watching development of this client for a year now, and there's all sorts of wonderful new features for downloaders (web, RSS, etc), and the development pace is to die for -- but there's been hardly a bone thrown to initial-seeders (who make all the torrents for everyone else in the first place). To make matters worse, this hideous bug means that, if I must restart for some reason, I'll be made to re-tread old ground from piece #0 even if the torrent isn't complete yet -- this makes it hard to upload rear-end pieces in initial-seeding mode in bigger torrents, since the longer it takes to upload, the greater chance of needing to restart. (I've previously requested the ability to adjust the next piece marker, and haven't had any indication whether or not it was being considered.)

[Greg Hazel]

Just letting you know I am reading these

I'll put some thought in to improvements, but not using the feature myself means I don't come up with ideas daily. Detailed ideal client behaviour would help (not "when BitComet does this do that" but more generally "try to do this so the swarm benefits that way")

[Switeck]

Does µTorrent v1.7.5 and later keep track of now-disconnected peer's percentage completed?

Also needed is what part of the torrent even the disconnected peers had, because they likely will reconnect or even still have connections to other peers on the torrent...just not you.

A memory only needs to be kept of the last 100 disconnected peers at absolute most. Disconnected peers with nothing or only pieces duplicated by multiple other peers don't qualify as "interesting", but still need to be remembered due to possible disconnect/reconnect exploits. Oldest disconnected peers could be dropped to preserve space (ram and system stack) and prevent upload stalling. (Upload stalling might occur when all the connected peers are missing a section that the initial seed still remembers that it previously uploaded to a now-disconnected peer.)

Only when the initial seeder has uploaded every piece at least once should it seek to re-upload pieces only seen by now-disconnected peers. This should help spread rare pieces so peers can "fight among themselves" with what they already have.

Initial seeding should also have (if it doesn't already) strong support among µTorrent peers to seek out only rare parts (that no other peer reports having) from any seeds they are connected to.