[Snort-devel] Re: last_cid in new database scheme v106

Roman Danyliw roman at ...49...
Wed Sep 11 12:34:03 EDT 2002


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

Indeed, there is definitely overhead with this addition.

One possible optimization which should provide identical performance
characteristics as schema v105 would involve reading the sensor.last_cid
field at snort start-up, but not updating this field until snort is
shutdown.  Should snort crash, the existence of alerts after the last_cid
would be lost.  However, on restart, this condition could be detected and

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

Keeping a sentinel value would add additional complexity to the
applications processing 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.

Perhaps a configuration option could be added.  However, this would also
require indexing the signatures by their snort sid.


More information about the Snort-devel mailing list