Difference between revisions of "TODO"
From AMule Project FAQ
| Line 12: | Line 12: | ||
#Go on for Kademlia specific articles | #Go on for Kademlia specific articles | ||
#(Re)work on the utilities FAQs and articles ('''requires usage articles done''') | #(Re)work on the utilities FAQs and articles ('''requires usage articles done''') | ||
| − | #Permission failing (see [[TODO#Notes]]) into FAQ ('''requires FAQ rework done''') | + | #Permission failing and others (see [[TODO#Notes]]) into FAQ ('''requires FAQ rework done''') |
#Safe servers list into FAQ ('''requires FAQ rework done''') | #Safe servers list into FAQ ('''requires FAQ rework done''') | ||
#Document missing [[aMule_files|files]] and Kademlia files (and explain defaults in [[amule.conf_file|config file]]) | #Document missing [[aMule_files|files]] and Kademlia files (and explain defaults in [[amule.conf_file|config file]]) | ||
| Line 28: | Line 28: | ||
== Notes == | == Notes == | ||
| + | |||
| + | === First === | ||
[21:10] <Redarg> in the preferences the security tab is filled with : Files 664, Directory 775. In the temp directory and in the finished Directory the files get a 644 | [21:10] <Redarg> in the preferences the security tab is filled with : Files 664, Directory 775. In the temp directory and in the finished Directory the files get a 644 | ||
| Line 38: | Line 40: | ||
found the problem: ulimit, I didn't increase the max number of file descriptors the application could open... | found the problem: ulimit, I didn't increase the max number of file descriptors the application could open... | ||
| + | |||
| + | === Second === | ||
| + | |||
| + | Syntax : | ||
| + | |||
| + | ed2k::<md4hash> | ||
| + | or | ||
| + | ed2k:<size>:<md4hash> | ||
| + | |||
| + | I could add another special syntax like : | ||
| + | |||
| + | related::<md4hash> | ||
| + | |||
| + | So someone could try to search something like | ||
| + | |||
| + | related::<md4hash> AND Video AND SIZE > 1000000 | ||
| + | |||
| + | The server checks if the file is known. | ||
| + | |||
| + | If not -> End of request, 0 result. | ||
| + | If yes : It scans the list of clients that share this file. | ||
| + | |||
| + | A temporary 'working set' is inited to empty. | ||
| + | |||
| + | For each client in the list, it scans the list of its shares, adding found file in a working set : | ||
| + | |||
| + | If the file has a small #availability (like 1 : only one people share it), ignore it. | ||
| + | If the file (md4 hash) is already in the working set, adds 1 to the 'related count' | ||
| + | If not, check if the file meets the search criteria (if any was specified in the search req) | ||
| + | If the file meets the criteria, adds it to the working set with the 'related count' set to 1. | ||
| + | Some logic could be added to make sure the working set could not use too much ram (if a threshold is hit, just do a garbage collection to free half of the entries for example) | ||
| + | |||
| + | Then sort the working set byt the 'related count' key, and give the 300 files having the highers 'related count'. We then free the working set (no 'more' request could be asked to the server to get next 300 files, because keeping the working set in memory would be too expensive) | ||
Revision as of 13:23, 11 December 2005
Contents
Before we start
Check this wiki's FAQ if you haven't already taken a look at it.
Most urgent stuff
- Write good "aMule usage" documents (being worked)
- File details
- Networks & systray colours
- Transfers
- Preferences
- Go on for Kademlia specific articles
- (Re)work on the utilities FAQs and articles (requires usage articles done)
- Permission failing and others (see TODO#Notes) into FAQ (requires FAQ rework done)
- Safe servers list into FAQ (requires FAQ rework done)
- Document missing files and Kademlia files (and explain defaults in config file)
- Split large articles into smaller articles straight to topic (in process, stalled, requires FAQs, Kademlia and usage articles completed)
- Rework the Main Page and the whole wiki structure (requieres all the above done)
- Network packets and protocol design (and EC)
Someday stuff
- Only first word's appearance is linked in wiki
Always TODOs
- Translate this wiki's articles
Notes
First
[21:10] <Redarg> in the preferences the security tab is filled with : Files 664, Directory 775. In the temp directory and in the finished Directory the files get a 644 [21:17] <Redarg> 664 and 775 sounds good [21:18] <ken> Redarg, what does "umask" show? [21:19] <Redarg> 0022 [21:22] <ken> Well, that means "don't let files be read by group or others". It's causing the difference between the permissions you set in aMule preferences and those you're actually seeing. [21:23] <ken> You need to arrange for the command "umake 0002" to be run before aMule is run. Do that either in your shell startup commands, or in a script you use to launch amule. [21:24] <ken> s/umake/umask
found the problem: ulimit, I didn't increase the max number of file descriptors the application could open...
Second
Syntax :
ed2k::<md4hash> or ed2k:<size>:<md4hash>
I could add another special syntax like :
related::<md4hash>
So someone could try to search something like
related::<md4hash> AND Video AND SIZE > 1000000
The server checks if the file is known.
If not -> End of request, 0 result. If yes : It scans the list of clients that share this file.
A temporary 'working set' is inited to empty.
For each client in the list, it scans the list of its shares, adding found file in a working set :
If the file has a small #availability (like 1 : only one people share it), ignore it. If the file (md4 hash) is already in the working set, adds 1 to the 'related count' If not, check if the file meets the search criteria (if any was specified in the search req) If the file meets the criteria, adds it to the working set with the 'related count' set to 1. Some logic could be added to make sure the working set could not use too much ram (if a threshold is hit, just do a garbage collection to free half of the entries for example)
Then sort the working set byt the 'related count' key, and give the 300 files having the highers 'related count'. We then free the working set (no 'more' request could be asked to the server to get next 300 files, because keeping the working set in memory would be too expensive)
