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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
