New allocation code in SVN
I’ve just committed revision 128 to Niagara’s SVN, which reincorporates my updated block segmenting and allocation code. I’m happy to write a detailed comparison if anyone’s interested, but basically the old code stored a bitset for completed pieces (subsets of a block) and the index of the next request. This worked fine with a single peer per block system, but I noticed poor performance on torrents with large chunks (>1mb).
I was keen to debug this, and wrote the block display in Niagara so I’d know what was going on. I soon saw that a single peer per block was a bad idea, as you can imagine how long 4mb blocks take at 4kb/s.
I started my rewrite of the allocation algorithm by defaulting to putting 3 peers on a block before starting a new one. This caused a problem, as having only a single byte position to guide the next request meant a lot of overlapping data and waste.
I redesigned the allocation tracking system to include two bitsets, one for requested pieces and one for filled. This meant I could allocate any number of peers to a block and not overlap requests, and also enabled the more informative block display currently in SVN. It’s working really well, and I plan to release another alpha with the new code once I’ve implemented the next feature I really want - bandwidth limits!
The preference GUI for rate limiting is there because I had a terrible hack a few months ago while I was experimenting with limiting. I’ve come up with a much better system, and am currently implementing and testing it, so keep an eye on the blog for the next alpha - hopefully this week!