Initially seeding multi-file torrents

Regarding the problems discussed in: http://forum.utorrent.com/viewtopic.php?pid=259125

Proposed fix: uTorrent treats a multi-file torrent as several seperate torrents while initial-seeding.

Let's say a particular multi-file torrent looks like this:

[file1][file2][file3][file4][file5][file6]

We begin initial seeding, and some peers show up.:

PeerA ...wants file2 and file3; has others marked Don't download.

PeerB ...wants file3 and file4, with file4 marked high priority and file3 low priority.

PeerC ...wants file5 only, and is a leech with his UL throttled to 1k/sec.

PeerD ...wants file5 and file6; has others marked Don't download.

At this point, uTorrent won't send pieces to anyone because nobody wants file1 yet, despite the fact that all of the peers want at least some files that other peers also want (and will therefore theoretically share with each other).

Present dilemna: Turn on regular seeding, and PeerB tanks up on file4 while PeerC grabs file5 and then logs off before trading many pieces to PeerD. Or, keep everyone just sitting and wondering what the heck is going on, and hope none of them get bored and leave.

Now PeerE shows up. He's wants everything and has a T1 account with upload speed cranked to the moon. uTorrent sends him a nice, juicy piece #1. ....and then gives PeerE the cold shoulder because it thinks PeerE is a "leech" since his piece isn't showing up among peers who don't want it. If all the other peers were gone, uTorrent would give PeerE its undivided attention, and he'd build up a big stockpile of pieces to send to later-arriving peers.

It isn't until there are *two* peers who want file1 *and* have good upload speeds, that the torrent will begin to seed at more than snail-like rates.

I watch stuff like this go on in my new multi-file torrents all the time, and it's just a horrible pain in the butt until there's about fifteen or twenty or more peers. Sure: I could ZIP the thing up into one gargantuan hunk of mystery meat, but who wants that?

But let's say uTorrent treated each file as its own torrent. Then, straight away, PeerA and PeerD begin receiving pieces, and the moment PeerE shows up with his T1, it's party-time. (Edit) While the files are treated as individual torrents, they are still regarded as part of a "package", so files which have been initially seeded won't continue to seed if other files have pieces remaining to be issued; instead they'll be internally noted as "finished" unless peers possessing their pieces disappear.

http://forums.degreez.net/viewtopic.php?t=1989

I found this thread interesting... Now, I wonder if µTorrent actually does that, or if it just blocks indefinitely

From my anecdotal experience, uTorrent will indeed refrain from sending fast peers new initial-seed pieces until previously sent ones have appeared in slow-DL recipient peers. At least it certainly seems to sit on its fat ass for long periods of time before sending more pieces.

Regarding the multi-file torrents described above, if uTorrent worked as "TheShadow" maintains in your linked article, I'd never, ever stare at a list of peers all at 0.0% in a new, initially-seeding torrent who are never sent anything because none of them want the file with piece #0.

(Regards initial-seeding in general, I think uTorrent's implementation should have a mechanism for "remembering" good retrade behavior by peers, and thereby reward them with new pieces even when some previously sent pieces aren't yet being seen in other peers. For example, if uTorrent determines that PeerA re-traded ten pieces over five minutes, it will then just send him ten pieces every five minutes without tracking him...for awhile at least. (Records of such "behavior" would be periodically flushed and updated, or halted altogether after a certain number of peers or percentage completion is achieved.) EDIT: Added as request here: http://forum.utorrent.com/viewtopic.php?id=26229 )