Wouldn't it make sense to follow this logic... Do the positive weight tests (black tests) first in highest to lowest weight order.
If the action threshold is reached then skip to the negative weight tests (white tests) in the same order but keep your place so you can resume if needed. If a negative weight test drops the weight below the action threshold then bounce back to the positive list and continue where you left off until you finish or break the threshold again. Allow the system to bounce between black and white tests until the value stabilizes. Also include the optimization rule that the white tests never get run or resume if either the current weight is below the action threshold or the sum of the remaining tests would be insufficient to force it back across the threshold. Include a similar rule for the black tests. The result will be a system that adapts to the tests that are available in real time, only running the tests required to produce a determinate result. This is based on self organizing automata principles. It allows the population of tests to interact with eachother and reach a stable equilibrium in their "environment" (a determinate result) even when the population of active tests is unknown before each instance of run time. It sounds more complicated than it is. _M PS: In declude there is a wrinkle with this methodology. Since all DNS based tests are fired at once up front there is no obvious way to resolve the ordering of these tests... but this _might_ be solved by recognizing that most DNS interactions are UDP based... so it would be possible (and relatively inexpensive) to launch the queries for all of the potential DNS based tests up front, but to reserve the evaluation of each result in the appropriate order... if the system reached a state where the some of these tests were not going to be evaluated then those threads would simply die with no harm. Only Scott knows how his code is structured so this may or many not be an easy thing to do. I'm presuming it would be easy if each test were fired in it's own thread since that thread would spend most of it's time waiting (sleeping) for a response and the evaluation of that response could be encapsulated in a "result check" method for the test. >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of John >Tolmachoff (Lists) >Sent: Wednesday, June 04, 2003 2:02 AM >To: [EMAIL PROTECTED] >Subject: RE: [Declude.JunkMail] Easy way to add power and flexibility. > > >> Forgive the intrusion (I just troll here, don't actually have JM >> <yet>), but this idea seems flawed. If you quit testing once a >> certain weight has been reached, wouldn't you cut off >further testing >> that might reduce that weight? In a system where a score can go up >> and down depending on the test, unless there is a way to order the >> tests so negative weighted tests are run first, I'd think that all >> tests must be accounted for. > >Welcome Kurt. Yes, I agree with you. That is way I have stated >my hesitation at having this available, either as an option or feature. > >The weighting system is the weighting system and should be >allowed to work in its entirety. > >John Tolmachoff MCSE CSSA >Engineer/Consultant >eServices For You >www.eservicesforyou.com > > >--- >[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
