[Bro-Dev] Per item expiration for tables
Jan Grashöfer
jan.grashoefer at gmail.com
Mon Apr 11 14:05:41 PDT 2016
Hi Robin,
> I understand the motivation but I would prefer to stick with existing
> mechanisms, as per item expiration times can get expensive (that would
> require storing an additional float for all table entries). It might
> also be a bit too specialized a use case to add new syntax to support
> it.
While I think adding a float for table entries would not be too
expensive (considering the common dimensions of Bro-deployments), I can
follow that this is an edge case, which might not justify to introduce
new bifs or even syntax support.
> Let me try an idea: could you limit the set if expiration times to a
> predefined list of choices (e.g., 10mins, 1hr, 1d, 1w, 1m)? Then you
> could work with a set of tables with corresponding expiration
> intervals.
I am not sure I get that right. Wouldn't that require a lot of duplicate
code (at least for the table declarations)?
My alternative would be to implement a (configurable) timeout and allow
timeout values that are multiples of this value. Another approach could
be to allow any timeout values, use a single table timeout for "garbage
collection" of expired entries and check validity on every match. But I
think the last approach would introduce significant overhead.
Best regards,
Jan
More information about the bro-dev
mailing list