Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Friday, February 04, 2005

Intermodule deps; PartData v2 passes regress-testing

Yesterday I had to lend my CPU resources for some video encoding for some quick cash (hey, kitty's gotta eat!), explaining the missing blog post. However, that forced break gave me chance to figure out inter-module dependancies engine, as well as add full 64-bit file I/O support capabilities.

The latter was rather simple - just needed _LARGE_FILES and _FILE_OFFSET_BITS defines enabled to get 64-bit STL IOStreams enabled (hydranode itself is fully 64-bit aware). The inter-modules dependancies thingie is somewhat more interesting tho.

The main problem with inter-module dependances is that when a module requires another module, we cannot really load the module unless all pre-requisites are already loaded. This is usually handled by platforms dynamic loader automatically when dealing with shared libraries in general, however, since we'r doing explicit shared library loading, we need to perform this step ourselves. Thus, the only way we can really get to know the dependancies of a module is via a support file - modulename.cfg (the extension may change during implementation). That configuration file will be looked for in the same dir as the module itself, and parsed by HydraNode dynamic loader, and then loading all module pre-requisites prior to the module itself. The file format will be XML, since it needs to be human-writable. For example, Kademlia module might declare it requires ed2k module, etc. The config file is not just limited to pre-requirements. It can include HTML description of the module (for displaying in user interface), and any other info we feel like putting there.

That was yesterday. Today was a full coding day - under the topic of PartData. While finalizing and testing the new PartData, I also found one bug in the new Range API (erasing range from RangeList where the begin offset of erased range == existing ranges begin offset), and one bug in hasher (it was reading 1 byte less during chunkhashes, and the regress-test was buggy and didn't catch it). Inside PartData, there were also a number of fixes, and improvements. At the end of the day, my nice download simulator is running smoothly, indicating PartData is ready for deployment. While saving/loading code wasn't regress-tested, due to the simplicity of that code, it'll be tested as soon as the API is deployed over existing codebase and put to use.

For the curious:
include/hn/partdata.h [479 lines]
src/partdata.cpp [531 lines]
src/hasher.cpp [168 lines]
include/hn/hasher.h [216 lines]

For the record - PartData v2 is still 500+ lines smaller than PartData v1, while doing everything the old PartData did, and much more, while being easier/safer to use (and modify), so we can conclude the rewrite was well worth the time and effort.

Madcat, ZzZz

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?