Hydranode Developer's Diary - Developer's Daily Diary: Lots of fixes & improvements

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

Monday, February 07, 2005

Lots of fixes & improvements

Been a pretty nice and progressive development day, and since it's 5am and I'm rather wired, I'll just stick to dumping a compact summary of today's CVS updates here and get to sleep. So here goes:

Temp files are now moved to completed dir
ED2KPacket::readPartMap() method now adds correct amount of chunk bits (it formerly added extra padding at the end).
ED2KClient now adds source masks and hashsets to PartData.
Fixed Client::DownloadInfo::write() method chunk-finding loop
Added getCompleted()[size], getSourceCnt() and getFullSourceCount() methods to PartData.
Terminal size is now negotiated between telnet client and hydranode telnet server as defined by RFC 1073. Terminal size updates are also passed as the window is resized.
Added `vd` [view downloads] command, which lists all current downloads
Removed obsolete Range stream output operator, which was causing broken temp files on random cases (oddly enough, Linux/x86/gcc didn't detect duplicate operator, but OSX gcc did :o)
Its now possible to build modules as [built_in]. To do so, compile module with -DBUILT_IN, and link the modules object files to final binary. (Currently needs to be done by hand, build-system support for it is problematic.
New bandwidth-calculation engine in Scheduler - instead of former real-time bandwidth tracking, we now track bandwidth at 100ms precision - should be enough for our needs. In my tests, 170+kb/s transfer speeds had no effect on overall application performance after this upgrade.
Cleaned up lots of extranous debug/trace messages from various files.
Trim new download filenames to avoid spaces at begin/end of filenames.
PartData now displays fancy graph during load.
SharedFile::isPartial() and SharedFile::isComplete() methods now properly handle the situation where we have PartData at 100% completed state.
PartData now detects itself when loading 100% complete temp file and attempts to complete itself again.
Fixed lock generation - now adheres more closely to requested size (it was always giving size - 1 locks).
PartData now resets itself completely if full rehash fails.
ShellClient includes a nice progress-o-meter for monitoring download state.

Only current problem I'm aware of right now would be fixed if I had a clue where the problem lies. Thing is, it seems we'r losing ~30kb data somewhere between downloading and the target file. When PartData thinks it's complete, and performs full rehash, the rehash fails, and further investigation showed that the resulting file from the download was ~30kb smaller than was expected. The wierdest thing is that the regress-test still runs flawlessly, so I'v got no clue whatsoever right now where the problem is. Hope tomorrow brings better luck in searching this [hopefully_last] bug.

Madcat, ZzZz

posted by Madcat # 4:46 AM

Comments:

"Trim new download filenames to avoid spaces at begin/end of filenames."

IMHO not a good idea. Changes on the filenames should be completely in the hands of the user, including any misleading whitespaces. Do it as option?

Maybe i am just missing the point, so could you explain it?

# posted by Anonymous : 12:04 PM

In general, it's useful to have automatic filename cleaners in place (like in eMule), however, you do have a point - such automatition can only be allowed if it doesn't interfere with user. Thus, implementing it in FilesList (inside core) was a violation of that. I'm currently looking into few possible solutions to have it customizable, extendable further via plugins, as well as overridable, and optional.

Madcat.

# posted by Madcat : 10:36 PM

Most *nix filesystems allow for whitespaces at the beginning/end of filenames. They also allow for a lot more characters in the filenames, and I'm not talking about lenghth here. ? * " > < | are perfectly valid characters on a ReiserFS syustem, for example.

Beginning or trailing whitespaces can be annoying, but they can also serve a speciffic purpose, so just eliminating them without asking is not a good solution in my oppinion.

# posted by Anonymous : 6:32 PM

If you do use such characters in a shared file, other users may have a problem when they attmept to download it to the default filename. A similar problem exists with p2p apps support of >4GB files, while people with NTFS and linux filesystems can download and share them, windows 98/FAT32 cannot.

# posted by Anonymous : 8:49 PM