[Bro-Dev] Configurable &write_expire interval
Aashish Sharma
asharma at lbl.gov
Fri Jun 10 11:05:55 PDT 2016
HI Jan,
> > A solution could be to evaluate the interval expression every time it is
> > used inside the table implementation. The drawback would be that there
For all of my needs above has worked fairly well. including using exp_val= 0 secs as default.
Based on the value of item in the table, I could return a variable time back from the expire function thus either keeping it longer or expiring it.
> > used inside the table implementation. The drawback would be that there
> > is no fixed value for serialization (I am not sure about the effects
Sorry, I don't quite seem to understand this drawback.
Aashish
On Wed, Jun 08, 2016 at 08:30:14PM +0200, Jan Grashöfer wrote:
> My explanations might be hard to follow without examples. So I am adding
> some pseudo code:
>
> > I ran into an issue while trying to make the &write_expire interval
> > configurable: Using a redefable constant does not work here, as the
> > expression only gets evaluated when the table is initialized and thus
> > later redefs do not influence the value.
>
> # base script:
> const exp_val = 5min &redef;
> data: table[addr] of string &write_expire=exp_val;
>
> # user script:
> redef exp_val = 20min; # has no effect
>
> > I thought about circumventing
> > this by setting the value to 0 and maintain an extra variable to check
> > against in my expire_func and return the right value. Unfortunately this
> > won't work with write/read_expire as a write or read will reset the
> > expiration to the initial value of 0.
>
> # base script:
> const exp_val = 5min &redef;
>
> function do_exp(data: table[addr] of string, idx: addr): interval
> {
> if ( is_first_call() )
> return exp_val;
> # in case of a write, expire timer will be reset to 0
> else
> ...
> }
>
> data: table[addr] of string &write_expire=0 expire_func=do_exp;
>
> > A solution could be to evaluate the interval expression every time it is
> > used inside the table implementation. The drawback would be that there
> > is no fixed value for serialization (I am not sure about the effects
> > here). Another solution would be to provide a bif (or implement a
> > language feature) to change the expire_time value from inside the
> > expire_func.
>
> # base script:
> function do_exp(data: table[addr] of string, idx: addr): interval
> {
> if ( is_first_call() )
> expire exp_val; # sets expire timer instead of delay
> else
> ...
> }
>
> > There was a somehow similar discussion about per item expiration (see
> > http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2016-April/011731.html)
> > in which Robin came up with the solution of multiple tables with
> > different expiration values. Again this would be a solution but doesn't
> > feel right (duplicate code, static and somehow counterintuitive for the
> > user).
>
> # base script:
> type exp_interval enum { ei1m, ei10m, ... };
> const exp_val = ei1m &redef;
>
> data1m: table[addr] of string &write_expire=1min;
> data10m: table[addr] of string &write_expire=10min;
> ...
> data1d: table[addr] of string &write_expire=1day;
>
> function insert(...)
> {
> switch ( exp_val )
> {
> case ei1m:
> data1m[...] = ...
> break;
> case ei10m:
> data10m[...] = ...
> break;
> ...
> }
> }
>
> # user script:
> redef exp_val = ei30m;
>
> > Maybe I am missing something regarding the loading sequence of scripts
> > and this problem could be solved easier. So I am open for any
> > suggestions or feedback!
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
More information about the bro-dev
mailing list