[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