Hydranode Developer's Diary - Developer's Daily Diary: Goodbye Callback lib, hello fast ipfilter loading

Alo Sarv
lead developer

Donate via
MoneyBookers

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

irc.hydranode.com/#hydranode

Friday, January 21, 2005

Goodbye Callback lib, hello fast ipfilter loading

Finally I got rid of the Callback functors library, which was the original base of Event subsystem, and used also in Log and DSH (Data Structures Hierarchy, otherwise known as Object) systems. 1500 lines less code to be parsed during each file compilation :) The Log subsystem was changed to use Boost.Signals library, The Object was changed to use Event subsystem for it's work.

Moving on, IpFilter can now also load emule-format ipfilter.dat file (format is detected automagically). Due to some syntactical differences in ipfilter.dat format, inet_addr() was incapable of converting the addresses found in there (it has leading zeros e.g. 004.063.128.006, which inet_addr() considers as octal numbers). So, I decided it's great time to bring out the big guns - Boost.Spirit. 'lo and behold - IpFilter parsing times just got reduced 50% - now I can load ipfilters (both formats) in 0.17s (in release build). Boost.Spirit seems to be highly optimizable, since in debug build, the load times were nearly 10 times slower. However, what matters is release build anyway, so ...

In other news, I finally made a breakthrough on new PartData engine - namely the ChooseRarestIncompleteChunk concept which had been bothering me for ages. Now I have a basic design and proof-of-concept on how it should work, which is a big step towards actually implementing the new PartData we'v all been waiting for. More on this in the coming days/weeks.

On other news... er wait, I said that already. *sighs*. Well, anyway, Boost.ProgramOptions library doesn't seem to quite cut it - at least I can't find any reason why we should drop my current Config/Prefs engine in favour of that one, so guess that's one item off my short-term roadmap.

Madcat, ZzZz

posted by Madcat # 9:22 AM

Comments:

is the peerguardian format supported? and will compressed files be supported for ipfilter type lists ( downloading zip files reduces bandwisth consumption for the host site ) ?

# posted by Anonymous : 10:17 AM

where will configuration be stored in deamon/service mode? /etc, user homedir or the path where the deamon is run from?

# posted by Anonymous : 2:58 PM

The files should follow the right hierarcy (depented on the OS).
For example on linux libraries should go under '/usr/lib/hydranode/', executables under '/usr/bin/' etc. As for the configuration files, these should be under '/home/USER/.hydranode/', and have an option like "--conf-dir=/etc/hydranode/" so that we can set up the core as a proper daemon through "init.d".

On windows all files should be in 'C:\Program Files\Hydranode' and confs under 'C:\Documents and Settings\USER\...'

This isn't as complicated as it sounds and is what a true multiuser program should do.

# posted by Anonymous : 5:40 PM

> is the peerguardian format supported? and will compressed
> files be supported for ipfilter type lists ( downloading
> zip files reduces bandwisth consumption for the host site )
> ?
Yes (that's what I meant under mldonkey format) and yes (autoupdater will download & unpack the zip archive).

> The files should follow the right hierarcy (depented on the
> OS). For example on linux libraries should go under
> '/usr/lib/hydranode/', executables under '/usr/bin/' etc. As
> for the configuration files, these should be under
> '/home/USER/.hydranode/', and have an option like
> "--conf-dir=/etc/hydranode/" so that we can set up the core
> as a proper daemon through "init.d".
>
> On windows all files should be in 'C:\Program
> Files\Hydranode' and confs under 'C:\Documents and
> Settings\USER\...'
Yes. Partially already done so.

Madcat.

# posted by Madcat : 6:47 PM