[Snort-devel] multithreaded snort

Dirk Geschke Dirk_Geschke at ...802...
Fri Jan 30 20:44:16 EST 2004


Hi Peter,

> 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.

not really. Most #ifdefs handle the way how to talk to the dabase,
e.g. how to perform an INSERT. This won't change with the database
design.

> Maintaining the different files really is not a big deal as the underlying
> schema is not going to change that often.

Yes and No. But if there are not much changes then you don't need
to touch the output plugin at all...

But if you find for example a bug within an INSERT statement then 
you fix it now for all databases at once. If you have separate files
then you have to check all these separate files for the same error.

I guess on time this will result in diverging codes.

> 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
> DBMS's.
> 
> 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
> spo_database.
> 
> 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 think the best solution would not be to split the output plugins
in different files for each databas. It would be much better to have
separate files for routines like

DBConnect()
DBInsert()
DBSelect()
DBClose()

These files would have still the same #ifdef statements for all the
different databases but the main database code would be "clean" of
different database code. This makes teh main code more readable.

But additionally I still think that you should never use the 
database plugin within snort. If the database access is slow
then it is likely that snort misses some packets due to the
timeout caused for waiting of the output plugin. (This was
one reason to write FLoP...)

Best regards

Dirk







More information about the Snort-devel mailing list