[Bro-Dev] active_conns

[Seth Hall]

On Mar 18, 2011, at 11:30 AM, Robin Sommer wrote:

> On Thu, Mar 17, 2011 at 16:41 -0700, you wrote:
> 
>> I like the idea, however, I guess one question would be what the memory
>> overhead would be.
> 
> Wouldn't be very concerned about that. It's not much per connection
> (compared to how much we already store ...)

I'm sort of tempted in the base scripts to maintain fairly minimal logging and then have other scripts that add lots of extra state if people want it, but I also really want to avoid making things complicated again.  I like being able to do http logging by just loading "http".  Perhaps we could have these state extension scripts loaded by default, but if you load some other script (minimal-logging.bro?), it would not load the extended state scripts and give you very minimal state tracking for if you are doing something that doesn't need the full load of information and you have some memory constraint?

Of course, that's increasing the complexity of the base scripts again.  If someone really has the need to conserve memory that badly, they could always trim code out of the shipped scripts which should be quite a bit easier with the new scripts (not that I'd *want* people to edit the base scripts, it's just that they could).  Most of those state tables don't occupy *that* much memory at any one point in time anyway since they're cleaned up after the connection.

> , and just by not having
> some of the other high volume tables (like http_sessions) we'd
> probably compensate for quite a bit alredy.

I was just about to write here that I would like to keep it as it is for now, but then I started writing some example code to see how it would look if it was stored in the connection record and I sort of like it.

State stored in connection record:
	print c$http_session$log$method;

State stored in separate global table:
	print HTTP::active_conns[c$id]$log$method;

What I *don't* like about this model is that it breaks down when you have data that is stored about something outside of a connection.  My current example for this is TLS session IDs which are tracked in a state table so that the same previously established TLS session ID can be used in a different TCP connection.  You would then have to resort to storing the sessions IDs in a global table which makes the data storage less regular.  It may be worth it to get the syntax benefits though.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/