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

Sunday, March 13, 2005

Bugfixes and global UDP support

In order to address the IO buffers bugs in Scheduler, mentioned in previous blog post, I rewrote the IO buffers handling completely in scheduler. While originally the buffers were stored as raw std::string pointers in separate maps, and located from there whenever needed, the new implementation uses shared-pointers, and the buffers are located in SSocketWrapper class, which wraps around each and every socket stored in scheduler. The result was lot safer, and somewhat faster, and cleaner buffers handling.

Since we don't really want to use assert() (being C-style, and so on), I added CHECK_FAIL() macro to osdep.h, which behaves essencially the same - calling logFatalError() in debug-build, and doing nothing in release build.

In ED2K::Client-related classes, all debug-logging was moved to trace-log, to clean up the output in release build.

Global source queries are now fully operational. The bug was rather stupid really - when choosing file(s) to query for, I was checking for FileHashType != Ed2KHash, thus skipping all temp files. After fixing that, and adding support for Advanced (send more than one hash per request), and Extended (also send filesize in request) Server UDP protocol features, we now receive sources from all servers. The server's list is being rotated, queries done at regular intervals, while ensuring no server gets asked twice per 20-minute period. Downloads list (in queries) is also being rotated, each next query uses the file that was asked for the longest time ago, ensuring all files get equal amount of queries done with them.

The crashes on file-completition are still open tho. Some tracking showed that it's definately an issue with event-handlers de-registration upon handler's destruction, but from what I can see, I'v already done everything right - the object is boost::signals::trackable, which should provide automatic signal disconnection; I'm also explicitly disconnecting all connections on destruction... and STILL I get events submitted to objects that are destroyed, leading to invalid memory accesses ... wierd.

Madcat, ZzZz



Comments: Post a Comment



<< Home

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