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

Thursday, December 22, 2005

Cgcomm, Win2k3 issues and The Resolver

First off, great thanks to everyone who has donated so far. It's one thing to get thank-you mails once in a while, but it's completely different topic to actually see physical evidence that what I'm doing here is truly worth doing. So once again, thanks.

In that spirit, I'm thinking more and more towards user interface-related code, since this IS the single-most-wanted feature of Hydranode that's pending. After reviewing and tuning cgcomm code somewhat, I realized that we'r actually lot closer to workable UI samples than I originally thought. The side-project I did a while ago, called launcher or console, while by itself being a failure, it boosted cgcomm quite far before I stopped working on it. Now, going on a second run, I'v been tweaking the cgcomm, adding some features, and doing quite a bit of testing on it, and am actually quite pleased with where it's going.

Some things I realized - code reuse. GUI will be using quite a bit of core data structures internally, such as RangeList API, few Utils functions (bytesToString for example), and so on, so I'm thinking about making GUI depend on hnbase library, which contains those classes. That way I can transmit, say, RangeList objects directly over cgcomm, and load them on GUI side directly into the same type, which re-uses the same code (all such types support both saving and loading from stream). Naturally we won't be using events or sockets from hnbase, but it doesn't cause any bloat either, since hnbase dll is shipped with the app anyway. There's some issues right now tho related to that, since core uses msvc-compiled hnbase (and boost) libs, while GUI uses mingw-gcc compiler. Of-course we have the option of using mingw-gcc for both, but I don't really want to use that for core, since it's slow and creates huge binaries.

Disclaimer: working on GUI-related topics doesn't mean in any way that work on BT or other things is stopped. I'm merely opening up more development directions, to avoid having to work at same topic for long periods of time (gets really boring). Furthermore, GUI development requires quite a bit of features at core side on a regular basis (for example search page instantly requires global search capabilities, and I already discovered that FilesList's internal data structure's two indexes actually get broken on file completition), so it's all good.

Another topic that I'v been turning my attention towards is Enig123, who's been complaining about lot of issues with Hydranode on Windows 2003 server. Namely, the issues he's experiencing are Hydranode not being able to fill 51kb/s, or even 35kb/s upstream out of his 512kbit upload pipe (while other p2p clients can). Furthermore, after about 15-20 hours runtime, the entire networking becomes unusable, until a restart is made. Personally I cannot reproduce the symtoms either on WinXP/SP2 system nor a Linux system, on both of which Hydranode can easily use up 50kb/s upstream pipe and can run for many days without problems (the current official Hydranode uptime record belongs to frop, at over 1 month). Has anyone else experienced similar symtoms, and on what platforms?

Yet another thing that's becoming more and more inconvenient is the Resolver subsystem, written by cyberz a while ago. Originally inconveniences were simple lack of timeout handling, but the issues seem to be escalating, now it sometimes fails to resolve addresses that actually are resolvable. Which got me thinking - in the original ticket for the feature, I recommended thread + blocking API calls-based implementation, but it was later implemented by manually implementing the DNS protocol, resulting in about 2500-line code. Now I'm thinking maybe my original choice was still the right one - simpler implementation (I predict under 500 lines), meaning better maintainable, and has the benefit of using OS DNS cache transparently. So I'm thinking about a complete rewrite of the resolver subsystem in hnbase library. There hasn't been a single subsystem in core that hasn't been rewritten at least once, and rewriting/refactoring is a normal part of software-engineering process, so... "Prepare to throw one away; you will, anyhow." - Eric. S. Raymond.

Madcat, ZzZz

Comments: Post a Comment

<< Home

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