• Torrent files with announce-list keys are now parsed properly; tracker urls starting with udp:// are also handled correctly (altough I have no idea what they are - any1?)
• XP SP2 support, friendlier router support: Introducing NewConnsPerSec configuration value. This is generally similar to eMule's "New connections per 5 seconds", except the value is per 1 sec. Default 10 for Windows and 100 for Linux, however no matter the setting, only one new connection is allowed per event loop. (Hydranode event loop is at 50ms timeout, but runs faster when there's more network IO happening).
• In BT module Client handling, fast sources no longer add their requested chunks to the "shared" request pool; this lowers the amount of duplicate data and request canceling near the end of download somewhat.
• Fixed a really annoying bug in BT virtual file wrappers, where on corruption, the master-file's completed map was never updated, thus resulting in hard-to-detect ChunkSelector error (unable to generate chunk while download is missing 1 byte).
• In PartData, Chunks used to update their internal members w/o updating the master ChunkMap, which could cause inconsistencies and undefined behavior in the map structure / lookups. This no longer happens, altough comes with small performance penalty (additional lookups are neccesery when completing chunks).
• Downloads are now auto-paused also when flushing fails; this usually happens on Linux filesystems, where we cannot pre-allocate all required disk space, and resulted in huge memory consumption when downloading with full disk (all downloaded data was kept in memory, waiting to be flushed, but flushes kept failing). Downloads are auto-resumed once space becomes available again.

Now, with that out of the way, we can get back to the interesting stuff. I realized I went all wrong with the cgcomm library - it was just hacked together w/o proper design. What must be done is a full API design for the library; it should act and feel like it was direct link to core, completely hiding the fact that the core is actually a separate process. Basically, it would almost duplicate much of the hncore API (but not hnbase), providing proper iterator-based interface (we all love iterators, don't we? :)), signals on updates and so on and so forth.

On top of that, we will have QT Model classes (derived from QAbstractItemModel or similar), which wrap around the cgcomm library interface; and on top of that, we will have QT View classes (QAbstractItemView and derived), which finally expose the entire thing to the user. This design fits nicely into QT Model/View Programming architecture, and decouples GUI handling from the data, allowing any of the components to vary independantly; here we even have two layers - cgcomm library, which allows user interfaces to vary and QT Model classes on top of that, which allow views to vary (we can provide different views of same data structure very easily).

On the GUI topic itself, I figured since I don't have the designer resources right now to accomplish the most ambitious goals, I'll have to scale back the requirements, and (at least initially) come up with a simpler UI, that's mainly based on native/default controls; since all of hydranode is so damn modular and so on and so forth, we can swap out user interfaces, or parts of it very easily at any point down the road, when better resources become available.

Madcat, ZzZz