Goal of this library

To create a solid (somewhat robust) fake share / cheating detector that gives very few false positives while keeping the number of false negatives to a reasonable level.

Classes/components I need

This is a basic list. More should come. Preferably with detail.
dia files are being worked on (don't worry, I'll make a PNG for you to drool over too, and maybe I'll use dia2code to make the class files).
It won't be done "soon", however, so keep your pants on (always a good idea unless you really wish to get intimate with someone).

FileListEvaluator

• Finding certain files according to filters/patterns
• Finding duplicates of files

• Settings for anything that the file list evaluator could need
• Yatzy game? ;-)

• Filelist information
  • Start time of filelist retrieval
  • State of filelist retrieval - done, failed (due to <reason>), not started, started
• User information
  • Description
  • Description tag
  • Protocol information
    • lock
    • key
    • $Supports result
    • response of $GetInfo (or whatever the name is for the NM DC 2.0 command)
• Search slot information (used to determine whether someone is lying about their currently open number of slots).
  • Last time of search slot-specification
  • Last result of search slot-specification
• Response on entering the hub
  • "No Slots Available" on hub entry should be frowned upon.
  • Currently this may (and will) be caused by a valid user BUT a malicious client.
• Phony file request - generate (and verify!) a nice little non-existant filename
  • DC++ normally evaluates whether a file exists or not BEFORE considering if it can serve the request.
    This means that if someone would, say, try to use a file list but not serve any files they might forget to evaluate whether a file "should" exist in the share and instead always respond with "No Slots Available" error-code.
  • In any case, by using a phony file request, we could figure whether the client in question does in fact work like a DC++ client or not.
    NOTE: This does not mean that the user is cheating, merely that they are using a client that does not work like DC++.
    Err... even so, there are very few reasons for a client that does this AND exhibits a DC++ like tag, lock and/or key to be considered as anything other than a cheating, lying "hacked"/modified client.

• Data about a user for anything that the user evaluator could need
• ... errr... currently the UserEvaluator contains some things that should go here. <cough>. Sorry for that.

• Whether a user is a cheater/faker/bad apple
• Why the user is such an unrepentent malefactor
• How the user can mend their ways (if at all, and no creative things using various metal-based implements and bodily cavities)

Various things to consider

Interfaces to the whole thing. Keep them as generic as possible. Make evalations functions (sorta like "With these settings, is this user with this data a cheater and if so, why?").
Create an interface with a current DC++ version. Make sure to keep the "integration points" few and small. Oh, and cure the common cold while you're at it, won'tcha? :-)
Make nasty threats of all DC++ modders so that they integrate the thing in their programs. This would lead to less "Oh plz plz plz make a DC++<INSERT MOD NAME HERE>k version!!!!1" messages/mails.

You, the evil user

Please send your comments to me. As usual, don't forget to remove the exclamation marks in the mail address.
If you have to send criticism, please make it constructive - otherwise I'll cry and huddle up in a corner, and we don't want that, now do we? :-)

Site design by Atomic Jo.
Do you have any questions? Suggestions? Indecent proposals (I wish!) ?
Then mail me! Don't forget to remove the exclamation marks in the mail address.