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, October 09, 2005

Teaching cmod_bt to play with other kitties

Seems the optimizations I did last night weren't a waste of time after-all - testers reported today CPU usage drop of nearly six times, from 60% to 11%, in debug builds, on 200mhz pentium pro. Granted, your milage may vary, but seems the optimizations have larger effect on slower systems.

Today I was trying to make "BT" module play along better with other modules. As you are aware, I wrote it as standalone app initially, to speed up the development process (going through hnsh every time to start new downloads would'v gotten really tedious). However, now we need to turn it into a well-behaving hydranode module. Re-compiling the code as module wasn't any problem; I also ran initial tests in cooperative downloading with other networks - http and ed2k, both which currently have those capabilities. Both tests "kinda" worked - http module properly initated BT download, however due to problems on BT side, BT module created a new download instead of attaching itself to the existing one. ED2K integration worked better, since there BT initated the downloads, and ed2k is much more mature module. The downloading was nicely coordinated, same file was transfered simultaneously from both modules. Problems appeared, however when the files got to 100% - BT module didn't allow the files to be completed, since there were still hashes not verified (BT hashes can exceed file boundaries, if you recall my earlier posts).

As for the uploadmanagement, and the comments on previous blog post, seems I still have some thinking to do in that area before jumping to implementation. I still think the top-level handling should be by module's session up/down ratio, maybe slightly modified by the module's priority (3 priorities are currently defined for modules - low/normal/high). In addition to that, we need two "exceptions" - focusing all upload bandwidth to one (or more) file [is this really uploadmanager's job? files selection is done per-module basis; ok, perhaps focus file + network - release made to ed2k network?], and focusing all upload bandwidith to one (or more) clients (an ftp server is a "client" as well).

Let's take a look at usage scenarios:
  1. Normal operation, no user interaction. Each network is "rewarded" based on how much they have given us. All is fair.
  2. User has a list of "friends", to whom he prefers to upload. This should be handled per-plugin basis, to remain compatible with each networks netiquette for this. In ed2k, this modifies the requesting clients queue-score.
  3. User has set some shared files to high priority, some to low. As with friends, this should be handled at per-plugin basis, to remain compatible with each networks netiquette for this. In ed2k, this modifies the requesting clients queue-score.
  4. User releases a file to one network. User configures a percent of upload bandwidth (say 80% by default) for this file. The rest of the upload bandwidth is split as per rule #1.
  5. User wants to focus upload to a specific peer, let's say an FTP site. He configures a percent of upload bandwidth (say 80% by default) for that specific client.
Did I miss anything?

Madcat, ZzZz



Comments:
>Normal operation, no user interaction. Each network is "rewarded" based on how much they have given us. All is fair.

But shouldn't there be a minimun upload to each network? E.g. 10% (if 4. and 5. is not used)
 
If you haven't downloaded anything from a specific network, why should you upload to that specific network then?

Madcat.
 
Thinking more about the upload problem I believe it's in Hydranode's style to provide maximum customizability. So how about splitting the upload management in 3 layers. Lower layer implements anything - absolute, relative, conditional etc management. Middle layer implements "netiquette" constraints. Upper layer implements "business logic" - i.e. it's more geared towards what the user wants with priorities and such. Flow of requests is top-down so each layer uses what the lower gives him.

I see lot of trouble with a monolithic bandwidth management based on rules. At one point or another the rules will conflict and that's dangerous less Hydra be called "leecher".
GC
 
Yes, rules is dangerous, it can convert HN in a leecher thingie if "evil" guys get it used to...
 
Post a Comment



<< Home

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