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

Thursday, February 17, 2005

PartData fixed; misc fixes on ED2K::Client side

You know - if you tell people long and hard enough to leave you alone and stop disturbing you - they finally get the point, and do so. Thus, we'r back in action (for now, at least).

First and foremost, managed to fix PartData - the problem in there which caused file completition to fail was really stupid - I forgot to flush buffers before scheduling full rehash, so the last buffer contents were never written to disk, thus causing the hash to fail.

Also, made several fixes and improvements on ed2k side - namely, now it properly removes it's event handlers when partdata is destroyed (using boost::signals::connection objects, automatically disconnected when sourceinfo is destroyed also). FileStatus / FileName packets can, apparently, arrive at arbitary times, so when they do, we now handle them gracefully, and assume the sender is source for those (otherwise it wouldn't send them), if it's not already.

There seems to be some bug left in scheduler, namely, in handleDownloads() method:

uint32_t amount = getFreeDown() / pendingReqs;

void getFreeDown() { return getDownLimit() - getDownSpeed(); }

For some reason, getDownSpeed() returned larger number than getDownLimit(), which caused integer underflow, and moments later std::bad_alloc exception, since the amount variable was used to allocate data buffer. The assumption behind that code was that speed never exceeds limit, however, now that I start to think about it, I saw 160+kb/s transfer rates rather often during my earlier tests, with 100kb/s hardcoded download speed limit set... so I guess the download speed checker isn't functioning properly right now.

I added local workaround for the bug to avoid those crashes, so I could leave hydranode running overnight (dloading few 700mb files for testing), but the real fix needs to be worked on tomorrow (I'm not even going to commit this local fix - it's bad karma).

Madcat, ZzZz



Comments: Post a Comment



<< Home

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