[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