[Bro] connection_state_remove

Christian Kreibich christian at whoop.org
Tue Nov 29 16:38:30 PST 2005

On Tue, 2005-11-29 at 16:19 -0800, Robin Sommer wrote:
> On Tue, Nov 29, 2005 at 15:38 -0800, Christian Kreibich wrote:
> > could I please get a summary of when connection_state_remove is
> > triggered. 
> That's actually easy to summarize: connection_state_remove is
> triggered at the time Bro removes a connection's internal connection
> state, for whatever reason.
> In fact, the reason to introduce this was to get reliable clean-up
> of script-level state: if you have state which is stored per
> connection and not needed after the connection's removal,
> connection_state_remove is the way to reclaim it.

I see; but afaik UDP connection state is never expired (until
net_finish), right? My confusion about the semantics partially stem from
the fact that I see connection_state_remove used on non-TCP connections,
but I'm unclear about Bro's treatment of such connections.

> > It sounds like what I need, is mentioned in a bunch of places
> > in the code,
> There shouldn't be too many of these places. Essentially everywhere
> where a Connection object is destroyed. 

Okay, thanks. 

> > Some context: if I have a table[conn_id] of blah that indexes on both
> > UDP and TCP connection identifiers, then what's the best way to reliably
> > expire all of its entries as time progresses?
> Depends on whether you still need the entries when the internal
> state has already been thrown away. If so, then a read_expire may
> be the way to go. If not, connection_state_remove is probably better.

I indeed don't need it any more in this case, I just want to make sure
both TCP *and* UDP are expired. I'm aware of the difficulty of expiring
UDP state -- I just need some reasonable value that lets me run this
script on very large traces.

I guess I could just use separate tables and have a read_expire throw
out entries in the UDP table and connection_state_remove() handle the
ones in the TCP one, though given that conn_ids are so nicely identical
for UDP+TCP that'd seem a bit of a shame...


More information about the Bro mailing list