Since I have to wake up in 3 hours again to resume coding, I'll be brief tonight. A rather usual fix / improvement-set this time, with some new features. The list:
- [bt] Fixed tracker reasks (buffer wasn't cleared from last reask)
- [bt] Hydranode PeerID is now compatible with Azureus style
- [bt] Fixed bitfield parsing (bits were read in wrong order)
- [bt] Fixed cancel, have and some other messages sending
- [base] Exposed a crash-bug (in testsuite) when SSocket is destroyed while DNS query is in progress.
- [base] Connecting-state sockets are also counted towards total-connections, but connections weren't reduced when socket in that state was destroyed. This is now fixed (it caused a minor connection-count leak right now, but was exposed in a larger scale by the next patch)
- [core] Downloads can now be paused, stopped and resumed. The state is also saved between sessions. "Paused" downloads keep their old sources, but don't aquire new ones, "Stopped" downloads drop all current sources as well. Neither "paused" nor "stopped" downloads may be written to (altough data already written will be flushed to disk during next scheduled buffer flush).
- [base] SchedBase now allows changing connection-limit on runtime as well.
- [base] Added IntegerConcept check template to utils.h (based on Boost IntegerConcept check, but also adds 64bit integers to the mix).
- [base] Added concept-checks for Range and RangeList class.
Why the last two ones? That code hasn't changed in a long time, but as it turns out, it seems to be the strongest generic component we have in hnbase library. It is already used in PartData for completed/locked/verified et al range bookkeeping (the original purpose), for PartData chunk-map components, for IPFilter management (ip address is a 32bit integer really). And now, I figured I can use those classes for one more purpose - for BT files bookkeeping. That would replace the current, hand-crafted (and rather buggy) handling of sub-files in a torrent. The current implementation uses a map of files, keyed by begin offset, and does some really
wierd lookups there. However, I figure if I wrap a sub-file into something like this:
class InternalFile : public Range64 { SharedFile *m_file;};
Then this allows me to wrap the above into a RangeList
, that allows us to simply do m_children.getContains(offset), and find which file an offset belongs to. Cleaner code, less bugs, and all is happy :)
Madcat, ZzZz
