[Snort-devel] multithreaded snort

Peter_J_Moore at ...1684... Peter_J_Moore at ...1684...
Thu Jan 29 02:40:06 EST 2004

i have no comment on the threading suggestion at this point.

a redesign of the database schema would mean you will have to revisit all
of the #ifdef's anyway and really it is not much different if the various
DBMS's were in their own separate files.
Maintaining the different files really is not a big deal as the underlying
schema is not going to change that often.
There are better ways of handling the insertion/maintenance of snort data
in the various DBMS's instead of applying a "blanket approach" for all

Yes spo_database works fine as it is now, it's just a bit cluttered.

I am *not* suggesting an spo_postgresql or spo_mysql module to replace

What i am suggesting is that the code for these different DBMS's be
migrated out into their own files.
At compile time using --with-postgresql or --with-mysql (or whatever) and
that database support is built into spo_database exactly the way it is now.

i look forward to your thoughts.

Peter Moore
Senior Technical Specialist
Distributed Services - Internet, Intranet & Infrastructure
National Australia Bank

|         |           Dirk Geschke                |
|         |           <Dirk_Geschke at ...802...>     |
|         |           Sent by:                    |
|         |           snort-devel-admin at ...1685...|
|         |           ceforge.net                 |
|         |                                       |
|         |                                       |
|         |           01/28/2004 10:40 PM         |
|         |                                       |
  |                                                                                                                              |
  |       To:       Jost Kannegieser <jost.kannegieser at ...2342...>                                                              |
  |       cc:       snort-devel at lists.sourceforge.net, Dirk_Geschke at ...802...                                                     |
  |       Subject:  Re: [Snort-devel] multithreaded snort                                                                        |

Hi Jost,

> I agree to Peters suggestion - putting support for different DBMS's
> in different output modules is in general a good idea.
> This and running all DBMS's specific connect and insert stuff in
> seperate threads would IMHO bring snort to the next level of useability.

I think this is not a good idea at all. How about changes in the
code? Then you have to check all files for all databases? Who will
manage this? Or should be a maintainer for every database plugin?
Then the code will run off and you will never be able to find a
common line again. (Think of a redesign of the database and how to
implement this in the several codes...)

Further I don't think that it is a good idea to build threading
output plugins. I would strongly recommend to stick with one of
the existing solutions, either the unified output and barnyard/mudpit
or the unix socket approach used with FLoP.

If barnyard/mudpit/FLoP dies you can restart the service without
mayor problems. But if one output thread dies maybe due to a
SIGSEGV then the whole snort process will die. Of course you
can restart snort but be aware on what you are loosing. All data
of the preprocessors are gone, the whole establish functionality
is gone and has to be rebuild and so on.

So finally: These ideas are not very helpful in my eyes...

Best regards


The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
Snort-devel mailing list
Snort-devel at lists.sourceforge.net

More information about the Snort-devel mailing list