Saturday, February 5
Optimizing BitTorrent
I'm not talking about speed, I'm talking about the issue with some rather large torrent files out there that have no seeds, or at best, sporadic seeds showing up.
I think that a modification to the client would help fix this issue.
The client knows which pieces are the most rare. Certainly Azureus knows this. Instead of just grabbing random pieces, or the pieces for the front of the file, grab the pieces that only the seeds have. You wouldn't want to make all your download slots do this, but I bet if you had half of them doing this, and reprioritizing after each sync with the tracker, you'd find that the odds of completing a torrent without a seed would go up immensely, because you might actually get one entire copy spread out through all the clients. There's not like getting 90% or more done, and find out that you can't complete the torrent because there are no seeds up, or the seeder does come up, but it's too damn busy passing out pieces that other leechers already have.
That might be another optimization as well. If a piece is well populated, you never get it from the seeds and never request them from the seeds. This might be a range, so that if there are 100 leechers, but only 1 or 5 leechers have a piece or a certain small percentage of them, then it might be OK to grab it from the seed. Or if nobody that has that piece is allowing you to get it, then the seeder would be the last choice. This optimization would be a little harder, I think.
What I like about both of these optimizations is that the only changes neccessary need to be made on the client leeching side, not the seeder or tracking side. They seem to be practical. If I new Java programming, I'd be thinking about looking at the source and seeing if I couldn't at least get the first optimization done.
It's a thought. Permanent link posted by bytehead @ 2/05/2005 05:50:00 PM
0 comments
Links to this post
