I spent the weekend cleaning up the code to the greylist daemon [1], in preparation to releasing it [2]. Good thing too, because I've found lots of little details, a missed call to free() here, the wrong constant used there (it didn't matter before the cleanup, afterwards, with some stuff changed, it did), and not updating some statistical information correctly.
Little details like that.
The only big change was the ability to add and remove tuples using the master control program [3]. A nice side effect of that effort, you can now see how a tuple will be handled by the greylist daemon.
The other change is the way I handle stress testing. As a side issue about a parallel quicksort implementation [4], it was pointed out that the data I collected was bogus [5], and that I should be handling more requests than I am [6].
I got to thinking, and it may be that my current stress testing isn't stressful enough.
So I wrote a new stress test. This is basically two programs. The first reads through a list of tuples and generates all the packets, but saves them to a file. The second program maps this file into memory and then sends each packet, one after the other, to the greylist daemon.
My, what a difference.
The initial test was on an old 120MHz (megaHertz) machine. The previous stress test capped out at 77 requests per second. The new stress test capped out at 381 requests per second without a dropped packet (another test, this time the stress test program didn't bother waiting for a reply, managed to send 1700 packets a second—the greylist daemon could only handle 385 per second, and obviously dropped a bunch of packets).
Not bad for a 120MHz machine.
[4] http://my.opera.com/Vorlath/blog/2007/10/27/update-on-parallel-quicksort
[5] http://my.opera.com/Vorlath/blog/show.dml/1443460#comment3905805
[6] http://my.opera.com/Vorlath/blog/show.dml/1443460#comment3901357