robin at icir.org
Tue Nov 29 16:19:13 PST 2005
On Tue, Nov 29, 2005 at 15:38 -0800, Christian Kreibich wrote:
> could I please get a summary of when connection_state_remove is
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.
> 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.
> 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.
Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org
ICIR/ICSI * Fax +1 (510) 666-2956 * www.icir.org
More information about the Bro