New PartData API design is slowly, but surely evolving. An updated version can be seen
here. Most notable changes are also making LockRange an object, and bringing in HashRange (which will be the base of chunkhash maps implementation). As can be seen, the new PartData API is moving more towards nice object-oriented approach, compared to the old, rather clumsy mess.
From the implementation side, adding chunk masks works, and now I'm trying to figure out how should chunkselection done. We basically have a numbe of criterias to be considered when choosing a chunk (most likely in this order):
- Complete any partially downloaded chunks we have hashes for.
- Choose first and last chunk of the file (for preview) (optional)
- Choose least-available unused chunk
- Choose least-used / least-complete UsedRange
While the second and third are relativly easy to handle (the least-available-chunk selection system was designed a few days ago already), the first and last are rather complex to handle, so need more time to figure those out.
For those sitting around, watching and wondering "why is he wasting time on stuff like this when he should get ed2k downloading working instead?" - well, ed2k downloading has been working for quite some time - but the ranges get too fragmented near the end of the file, so the entire thing gets confused and it's hard to complete downloads. Hence the need for "complete any partial chunks" for example. As for the least-available chunk selecting, it should enhance the overall download handling significently, and also benefit the networks. So - worth spending time on.
Madcat, ZzZz