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

Sunday, April 23, 2006

FindServers option; Remote torrent downloads

6 days to release, and working down the TODO list. One thing that I forgot to mention in last blog post was the new 'FindServers' configuration option (in 'ed2k' section), which defaults to '1', but can be set to '0' to disable receiving servers from other servers and clients. This might be useful if you have your own server.met and don't want to have Hydranode filling it with fake servers all the time. Thanks go to dani_555 for requesting this feature.

A lot of time today went to getting 'double-click to open file' working properly from the interface. While it had partially worked for a while already, now it was time to get it working fully. There were a number of problems regarding opening completed downloads - the last update of the file that was sent to GUI still had the old location field set, and we couldn't modify it at hncore library side, since the PartData internally uses it to clean up it's mess on destruction. Instead, I opted to update the 'destination' field of PartData after the file is moved to incoming, and conditionally send that field as 'location' to user interface when the file is in 'completed' state.

That didn't fully resolve the issues though yet, since often core uses relative paths (the default incoming dir is config\incoming, for example); that didn't help the user interface much, since the gui can run at a different physical location than the core. The solution was to send all paths as absolute paths to the user interface, to ensure that the gui finds the files properly. Now it's possible to double-click on 'completed' files in download list to open them with the default application; same applies in library page, altough incomplete downloads (currently also shown on the library page) won't open properly, unless you have an application set to handle .tmp files (personally I use mplayer for that...). In the future, I hope to add an option to download & install mplayer with one click when attempting to preview temp files; alternative external players could be used upon user's decision as well.

Another thing that took roughly 3 hours was getting 'start torrent downloads from gui' feature implemented. This required changes at almost all levels of the Hydranode system - proper function at hncore/search.h, handler/changes in bittorrent module, support for the packets in cgcomm module and library, and finally ofcourse gui-side implementation. In the final implementation, the user interface opens up the requested file, loads all it's contents to memory and sends it to core over cgcomm. Core (cgcomm module) reads the data into memory, passes it to Search::downloadFile signal, to which Bittorrent module has a slot connected. Bittorrent module puts the std::string-contained data into std::istringstream and passes it to a slightly altered createTorrent() method, which then continues normally. When Bittorrent module loads torrents from local file, it merely passes the std::ifstream object to the same method.

Yet another thing that I spent several hours on was tracking, testing and debugging the notorious file allocation freezes on windows (and fat32/ntfs partitions in general). After extensive testing, it finally turned out that while I was seeking through the file, writing \0 characters (either one at the end, or one every 10mb's), that didn't cause proper space allocation at all, and the actual allocation was done still when PartData attempted to write data to somewhere in the middle of the file, causing the main thread to block. The thing is that Windows uses \0 character to fill the empty space of the file itself, and I was writing \0's as well, which windows simply ignored. As soon as I changed it to write '1' character instead, it allocated properly.

It should be noted as well that Hydranode uses single-go allocation now, which means the file is initially created at 0 bytes, and before the first buffer flush, it's resized to it's final size, which allows the operating system to optimize the file position on disk and reduce fragmentation. While it's impossible to truly avoid fragmentation when dealing with files, using this scheme, the operating system should place the file in a free continous block if it can find one, resulting in minimum amount of disk fragmentation.

Madcat, ZzZz

Great to hear your still on scedule and started to implement my favorite feature. Any plans to make a (simple) authorisation for the gui, that not everyone can connect to my core over the net?
And with the gui finished another module to transfer the files to a remote core would be interesting.
And I would be interested in the bandwidth used by cgcomm, the lsmod command does not show traffic for cgcomm and hnsh. And a way to decrease the update frequency of the transfer status windows.
And ... I guess I should start investigating in proper ways to file my feature suggestions...
Post them in the forum, thats where they are supposed to be posted and discussed. So far what i hear, it all sounds good to me.
When set "FindServers" to 0, hn even reject server descriptions from connected server. It might be a bug, but for now it's not a proper time to create more new tickets. That's why I mentioned here. Just hope Madcat can read it some time.
Looking at code, I can't see any reason why it should be happening. FindServers option affects two things in hncore/ed2k/serverlist.cpp - m_foundServerConn slot (it gets disconnected when the option is disabled to avoid getting servers from clients), whether GetServerList packet is sent after IdChange packet, and (as a safeguard) also in ServerList packet handler (just ignores the packet). Server names/descriptions are retrieved via UDP packets, which are not controlled via this option. Perhaps you are unreachable via UDP for some reason?

Post a Comment

<< Home

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