"Sole Seeder" mode

[MrB]

I haven't seen this suggested anywhere, but I think it would be incredibly useful to the community at large. Let me set up the scenario:

The one-and-only seeder of a torrent drops out. Note: this is not necessarily the original seeder of the torrent; he may just be the only one left. Everyone else only has, say, 90% of the pieces, and before too long everyone is stuck at 90% (except for any newcomers).

This has happened to me many times, and it's happening again now. The one-and-only seeder will come on for maybe an hour, and then drop out. The thing is, there's only about 20MB left in the torrent that a couple of dozen peers are waiting to receive. That should have been plenty of time, if only the seeder gave out that particular 20MB.

Hence my suggestion, "Sole Seeder" mode. In such a case, when the seeder comes back online, and he's using a hypothetical future version with this mode implemented, uTorrent would automatically realize that he's the only seeder, switch over to this mode, and give out the remaining pieces only, without repetition, until they're all given out. It would then revert to the normal seeding mode.

This would allow everyone in such a case to get a full copy as quickly as possible. Note that it wouldn't specifically wait for another seeder, just until all of the pieces were given out to enough peers that they could get the remainder from each other and become seeders without any more help from the sole seeder, in case he disappears again.

I'm anticipating a couple of questions:

"Isn't this the same as Initial Seeding mode?" Not quite. In Initial Seeding mode, uTorrent would give out ALL of the pieces, regardless of whether or not they were already represented by the connected peers. The basic concept is similar, though, and this could probably be implemented using the same code for Initial Seeding; you'd just have to put in something to consider the pieces that are already out there as no longer eligible, as if they had already been transmitted in Initial Seeding mode. Also, Initial Seeding mode isn't automatic, and the person seeding the torrent may not think to turn this on, especially if he wasn't actually the initial seeder.

"But won't the clients just be requesting the new pieces from the seeder anyway?" Yes, but the seeder would be giving out a lot of repeat pieces. With this mode, there wouldn't be that redundancy. It would also be using its bandwidth to give out pieces to newcomers that the other peers could have given to them; this would eliminate that as well. The idea is to get all of the remaining pieces out as quickly as possible.

"Couldn't you just do XYZ and end up with the same thing?" Maybe, but the user would have to realize that this is the case and take action accordingly. He might not be monitoring the state of the torrents. This mode would kick in automatically, and return to regular seeding mode once it had sent out all of the missing pieces.

Take that sole seeder that came on for a torrent I'm downloading this morning. He was on for about an hour, and there was about 20MB left. From the looks of things, he only uploaded a couple of megabytes. I'm SURE he sent out more data than this, but it was the same pieces in the unfinished area as well as pieces sent out to newcomers that the rest of us could have sent to them anyway.

You could upload 20MB in an hour at a rate of about 5kB/s. With this mode in his software, he could have easily finished the torrent before he went down again--even if he were seeding other torrents (perhaps Sole Seeder mode could automatically increase the torrent's priority until all the pieces are sent?)--and the rest of us would have a happy, healthy torrent with dozens of seeders.

As a wise man once said, "What do you think, sirs?"

[DreadWingKnight]

Automatic switching between normal and initial seeding mode has been requested and rejected before.

The functionality of this feature is covered in the initial seeding mode.

[MrB]

No, it isn't--please read my post again. What I'm talking about is similar to Initial Seeding, but distinctly different.

[DreadWingKnight]

Not quite. In Initial Seeding mode, uTorrent would give out ALL of the pieces, regardless of whether or not they were already represented by the connected peers.

False statement.

Initial seeding mode excludes already present pieces within the connected swarm. Any assumption for this feature based on your statement is automatically false because of it.

Sorry.

[MrB]

Ah, I wasn't aware of that. So the seeder coming in would have to notice that it's the case and switch to Initial Seeder mode, and that would do exactly what I'm describing?

Could you point me to the thread where this was discussed and rejected? I couldn't find it in a search.

[DreadWingKnight]

Looks like it got purged because it was so old, but the automatic switching between initial and normal seeding mode has been demonstrated to cause massive piece distribution problems in other clients.

[MrB]

I see.

What if this problem could be addressed in some other way, say, for example, by giving a higher priority to requests for pieces that no other peer has? In fact, that may not even require a separate mode of operation, just a change in how the client selects which requests to fulfill. Or would the same distribution problem apply?

It seems to me the advantages of getting more seeds out there would outweigh more minor issues with clients.

[jewelisheaven]

"What if this problem could be addressed in some other way, say, for example, by giving a higher priority to requests for pieces that no other peer has?" That is initial-seeding (aka super seeding)... Under 1.0 ratio, it fills piece GETs one at a time to different peers, until the peer sends out the piece you sent it, it doesn't get another. Repeat for next iteration of ratio integers... If you want to get seeds out more efficiently with least amount of upload cost it still behooves you to run in super/initial seeding mode. There have been people reporting their results and actual upload before new seeds are made, ranking uT as the lowest but I can not confirm uT is the most "efficient" to make N+1 seeds.

[Mihaimal]

Thing is I came here to suggest something in the same train of thoughts. I've read the discussion above and will not press on in a "come on, it's simple, just tweak this minor detail and it'll work" direction because that's obviously not the case.

However, there are situations when you just want to drive a nail through your head, and I wonder if there really isn't any solution, even if it involves human intervention. And I have the perfect example to illustrate the point.

The other day, I've reached 99.2% of a torrent, and had to wait an unbelievable 24 hours before being able to download the rest of 0.8% -- a matter of minutes under normal circumstances. And yes, there was a seeder just standing there with his 100% grinning in my face. Nothing I could do about it.

Now, two days later, I am an active seeder for the same torrent and I can see yet another guy stuck at 99.8%, certainly swearing at me from thousands of miles away (I'm not making any of this up; well, except the part about swearing, but even that is probably true). Again, nothing I can do about it -- I have my upload bandwidth full, and he's not being served. In this particular instance I would've been willing to micro-manage the whole thing and just ban all other peers temporarily, but (a) I couldn't even do that, and ( how often does the user notice such a thing and wants to micro-manage? Despite (, being able to micro-manage would've been a solution in this particular case -- maybe something along the lines of "Timed exclusivity", whereas that guy would've been the only one I'd serve for N minutes (or until he completed the download, whichever came first).

I realize I'm proposing a clunky solution for a very particular situation, but I suppose it's better than nothing, what with the open trackers these days which don't rely so much on karma (as if). Obviously, a smarter, more automated solution would be way better than this, but I guess this could be a first step in the right direction.

[MrB]

I (and dozens of others) have had 1MB left to go on one particular torrent. The seeder has been on briefly, but he hasn't given any of us any data; he's sent it all to newcomers and he's apparently sent parts of the torrent we already had. This has been going on for a week now. This is ridiculous. There has GOT to be some solution that's acceptable to the designers.

[jewelisheaven]

Is he running BitComet?

[MrB]

I'll see if I can check next time he's on. He's hard to catch.

[jewelisheaven]

I only ask because certain clients like bitcomet like to... seed profusely instead of efficiently I would also check out the place you got the torrent from to see if you can make a seed request, or PM the user to say (hey, I don't want to be a bother but you don't seem to stay on the swarm all that long when you DO connect, could you pause other torrents and let us finish right quick?) Also you may want to note the DNS of that seeder. It is possible it is an international line in which case there may be reasons he's not always on the swarm.

@ Mihaimal, you would be looking for http://utorrent.com/faq.php#What_is_ipfilter.dat.3F in reference to giving a guy exclusivity on a swarm. But the problem is, sometimes clients just don't want to talk to you... nothing uT can do about it, and certainly rewriting code for niche circumstances isn't something you want the overworked developers doing is it?

[Switeck]

MrB said, "I...had 1MB left to go on one particular torrent. The seeder has been on briefly, but he hasn't given any of us any data; he's sent it all to newcomers and he's apparently sent parts of the torrent we already had. This has been going on for a week now."

And this is just another reason why sequential downloading and priority first+last is BAD! Alot of the newcomers are demanding the first and last parts of files and sequential downloading, and since they have at least a slight priority over others to get a piece from the seed...they get to choose what parts they download unless the seeder is in initial seed mode.