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:
- Normal operation, no user interaction. Each network is "rewarded" based on how much they have given us. All is fair.
- 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.
- 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.
- 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.
- 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
