[Snort-devel] last_cid in new database scheme v106

Kreimendahl, Chad J Chad.Kreimendahl at ...1167...
Wed Sep 11 11:04:07 EDT 2002

Speaking practically... The primary key for all of these tables
shouldn't be sid,cid anyway.  There should only be one value (int?) as
the key.  This would easily prevent all collisions of CID, since a
sequence could be used (in most databases).   Then, use sid only as an
identifier, and only in the event table.   Structurally this is more
sound, and far more efficient for the DBs.  The next value could easily
be selected, and placed in the placeholders for its bound placeholder.
I'm in the process of trying to write a new database plugin
(database2?), that will use this new strucutre, as well as provide more
efficient means of insert/update/select statements.  The use of prepared
statements with bound placeholders will prevent the rebuilding of query
strings, and in the vast majority of databases, increase response
times... While only staying the same in others.

The other major reason for this is to prevent the error: "database:
oracle_error: ORA-01704: string literal too long."  which I would
consider a very major bug... Since this error does not truncate the data
when you get it, no data is entered into the field (the data_payload in
data field).  Which means, that even though the alert will appear in the
database, there will be no data for anyone to investigate whether or not
it was a positive.  This makes a large number of alerts pointless since
they are often overflows that are greater than the max length allowed in
a query string.  Placeholders/bound vars fix this.


Help with this is definitely appreciated...

-----Original Message-----
From: Dirk Geschke [mailto:dirk at ...972...] 
Sent: Tuesday, September 10, 2002 1:17 PM
To: snort-devel at lists.sourceforge.net
Cc: Dirk_Geschke at ...802...
Subject: [Snort-devel] last_cid in new database scheme v106

Hi all,

I understand the problem if you move the last entry of the database to
an archive database. After this is done there exists the possibility to
have a new database record with the same cid.

Therefore the last_cid was introduced to have one increasing value which
can't be used twice. This value is added to the sensor table.

But with this solution you have to increase this value whith each new
entry in the database. This is one additional entry with each call of

Wouldn't it be much smarter to take care of not to (re-)move the last
cid of the database? 

Additionally as last mentioned it would be much faster if we can trust
that each rule set is already part of the database. This would remove
a lot of query/insert statements and should result in a much faster
database logging.

Best regards


| Dr. Dirk Geschke            | E-mail: geschke at ...802...     |
| Gesellschaft fuer Netzwerk  | Tel.  : +49-(0)-89-991950-31 |
| und Unix Administration mbH | Fax   : +49-(0)-89-991950-99 |
| 85551 Kirchheim / Germany   | Raeter Stra/3e 26            |

This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
Snort-devel mailing list
Snort-devel at lists.sourceforge.net

More information about the Snort-devel mailing list