Transmission

Maybe this is a very unlikely situation but wouldn't it be possible for all uploading peers to not supply a certain block in a piece while being able to supply other blocks in that piece, therefore incorrectly triggering blockIteratorSkipCurrentPiece() when continuing to the next block in that piece ...

Yes the block count array will be huge. It could probably be an array of shorts or maybe even chars. I doubt the outstanding block request count would ever overflow a char. It's capped at 2 by my code until the 90% completion percent, at which point it becomes irrelevant anyway. And at the risk of ...

Ok will do next time sorry.

Looking at the code again, I'm not 100% sure why that behavior occurs. All I know is it was happening by using some debugging output. I think what happens is getPreferredPieces() returns the same pieces on each invocation (possibly in a different order, but they are still there until they are ...

The block request limit idea came after I tried changing the max outstanding requests per peer floor from 8->64 (in ratePulse in peer-msgs.c). It helped a little bit with regards to speed until I noticed that the refillPulse() in peer-mgr.c function was simply requesting the same 64 blocks from a ...

This patch is against official 1.75 source code. It might work with 1.76 (haven't tested). Its quick and dirty and may not help you at all, but my downloads used to peak at 200 kb/sec (on a 20mbit line), now I regularly get 1000kb/sec+. Give it a shot and post your results here.

http://pastie.org ...