TODO

Before we start

Check this wiki's FAQ if you haven't already taken a look at it.

Most urgent stuff

1. Write good "aMule usage" documents (being worked)
   1. File details
   2. Networks & systray colours
   3. Transfers
   4. Preferences
2. Go on for Kademlia specific articles
3. (Re)work on the utilities FAQs and articles (requires usage articles done)
4. Permission failing and others (see TODO#Notes) into FAQ (requires FAQ rework done)
5. Safe servers list into FAQ (requires FAQ rework done)
6. Document missing files and Kademlia files (and explain defaults in config file)
7. Split large articles into smaller articles straight to topic (in process, stalled, requires FAQs, Kademlia and usage articles completed)
8. Rework the Main Page and the whole wiki structure (requieres all the above done)
9. 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)