[Snort-devel] Re: last_cid in new database scheme v106
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
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