[Snort-devel] snort-2.0 and paengines
roesch at ...48...
Thu Jan 18 22:11:38 EST 2001
Todd Lewis wrote:
> Hi, everybody! A few questions relating to snort-2.0:
> 1) When will we open for business with 2.0?
RSN. I need to branch the CVS tree to make it official, but we're
probably going to do a 1.7.1 bug fix release in the next week or so
(which I'm probably insane for saying, every time I set a date we miss
> 2) Will the 1.7 code be the starting point?
Yes, no reason to throw out the 34000+ lines of code we have so far. :)
I'm thinking that part one of the transition will be a code cleanup,
streamlining and reducing where possible, eliminating bad/redundent
code, modularizing things that need it (rules parsers, etc), rewriting
the worst pieces of code (rules parser), and cleaning up comments and
some of the documentation.
> 3) Anyone object to my module code as outlined on the list?
I need to look at it more closely, but on first look it seemed to be
> 4) Anyone object to my paengine code as outlined on the list?
I like what I've seen so far.
> 5) In compiling paengine shared object modules, is it ok to be
> gcc-specific, or do I need to use libtool? Would it be ok for me to
> contribute gcc and let someone who knows how replace it with another
> build mechanism later on?
Well, we've been pretty gcc specific so far, I see no reason why we
can't continue to be. :)
> 6) Would there be any objection to my picking up the threading code and
> getting it working properly? I want to get some serious performance
> out of this release via the use of threading on MP machines.
Not from me. Fyodor? (The original threading code was Fyodor's, he's
the guy to ask about that. As we discussed, we should be very careful
to avoid negatively impacting the performance of the uniprocessor code
> 7) I notice that the present threading code assigns one thread per
> interface. I am curious as to why you could not just run one instance
> of snort per interface instead. Wouldn't the performance be the same?
> If I do take over the threading stuff, my disposition would be to move
> away from this model to a worker-pool model, where worker threads queue
> up to receive the next available packet from the paengine, serialized
> by a mutex; this would spread the workload even via packet acquisition
> mechanisms with a single entry point, like netfilter. Would there be
> any objections to this approach?
So you're proposing having one thread per packet and handling packet
asynchronously? That could present certain complications with things
that expect to see them in a synchronous fashion (defrag, stream, etc).
What about threading the output stage? Having the output section of
Snort be "non-blocking" (not really, but you know what I mean) would be
really nice, especially when we're doing slow DB inserts.
> 8) Are there any volunteers to review my paengine and/or module code
> as it presently exists and give me feedback?
I'm going to be looking at it, I need to a) understand it and b) make
sure I like it. :) From the level of your contributions so far, I don't
think B will be a problem.
> I am very excited about 2.0 and can't wait for us to get started on this!
Me too, we just have to approach it in a rational fashion and make sure
we do the things that *need* to be done before we get to the really fun
roesch at ...48...
More information about the Snort-devel