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 18, 2005

More on PartData

"All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run," or "I just found the last bug."" - Frederic P. Brooks, "The Mythical Man-Month"

What did I say about finding the last bug in PartData last night? Well, think again. But this time - really - this time I found the last of those PartData bugs. Really. Believe me, this is the last one! Now if I could only figure out how to fix it...

Thing is, apparently, writing data to disk never really worked at all. "How come?", you may ask. Well, when we'r downloading very small files, we get the data sequencially, and write to disk sequencially, and all is nice and groovy. However, as soon as things get complex, we need to seek around the file, writing data to random positions. Indeed I had the seeking code there, and naturally assumed that when I did myfile.seekp(begin); myfile.write(mydata);, it wrote the data to the indicated offset (wx, mfc and stdio behave this way). Dang, no it didn't. Instead, it seeked to the EOF, and wrote it there (incase where the offset was past EOF). So, then I go and say "mkay, so you don't want to seek past EOF... let's fill the file with nulls, and do our stuff then." Dang, now it INSERTS the data into the indicated position, instead of overwriting the nulls. Hum, ok, apparently, if I do myfile.seekp(amount, std::ios::end), it seeks past EOF correctly too, but the inserting problem still remains. I must be seriously missing something important here, because this can't be happening...

On other news, I discovered mldonkeys are sending us chunks twice ... at first, it looked rather wierd - why on earth would they send us chunks twice... but then I realized - mules (and compatible clients) use chunk-request-rotation system - you request chunk1, chunk2, chunk3, you get chunk1, then you request chunk2, chunk3, chunk4, and get chunk2, etc. However, mldonkeys (some new ones, which use id 0x0a), apparently don't understand this logic, and start sending chunk2 and chunk3 twice, in the above example. Now hydranode detects these clients, and requests each chunk only once from them.

Madcat, ZzZz

Post you comment on mldonkey to the mldoneky development forum

So long, bogeyman
From the mldonkey development forum:
"It's hydranode requesting chunks twice, (if you carefully read what madcat wrote, you'll notice that!) and mldonkeys response to send the data twice is absolutly correct behaviour!"
Post a Comment

<< Home

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