[Bro-Dev] 0MQ security considerations

[Gilbert Clark]

>> Coming back to the original question, in my view triggering all this
>> is not really justified just for doing threaded loggging. Longer term,
>> it may be fine.
>>     
>
> For just threaded logging, I agree. But this seems to be a rather
> general questions. I believe that just enhancing one component of Bro
> with thread support can lead to a problematic architecture in the long
> run, when other components also jump on the concurrency train. If this
> is not a coordinated effort, the components may crossfire and impede
> themselves. 

Okay, since this came up and I'm working on it, I guess I'll try to 
address the architecture issue :)

Originally, we were discussing using 0mq, which uses a message-based 
architecture.  This struck me as a very clean way to segment a program 
into threads, and would logically extend rather well to cover other 
things (e.g. IPC).  As such, I borrowed that model.

Bro threads, as I built them (read: my fault if this is bad / stupid :), 
are simply discrete event processors; they accept messages that descend 
from a parent EventMessage (or is it MessageEvent?  can't remember 
offhand) and are passed to the individual threads through a thread-safe 
queue.  Because there's a large degree of complexity involved with 
ensuring any individual event can be processed on any thread, especially 
given that log / flush / rotate messages have possibly complex ordering 
dependencies to deal with, and further given that a log writer (or, in 
bro's case, most of the logwriter-related events) should spend the 
majority of its time blocking for IO, I don't necessarily agree that 
logging stuff would be a good candidate for task-oriented execution.

Re: task-oriented execution for bro in general: this seems like it is 
already accomplished to a large degree by e.g. hardware that splits 
packets by the connection they belong to and routes them to the 
appropriate processing node in the bro cluster.  In this case, the 
hardware connection splitter thingy acts as the task scheduler, the 
packet acts as a task, and each individual bro instance acts as the 
thread of execution.  If we wanted to see aggregate performance gains, I 
guess we could write ubro: micro scripting language, rules are entirely 
resident in a piece of specialized hardware (CUDA?), processes only 
certain types of packet streams (thus freeing other general-purpose bro 
instances to handle other stuff).  We could even call it BroCluMP (Bro 
Cluster Multi-Processing) or something.

Naturally, in the case such hardware is not available, it might make 
sense to build a piece of software that could accomplish the same; I 
don't know enough about bro's cluster architecture to know whether or 
not something of this nature already exists, however.

> This could be as simple as thread thrashing but als manifest
> more subtle with poor caching and memory performance. 

Yes.  That said, this seems relevant: 
http://www.fullduplex.org/humor/2006/10/how-to-shoot-yourself-in-the-foot-in-any-programming-language/

> Maybe it's not
> warranted at this point, but I think we should at some point think about
> a task-based approach to concurrency, rather than thinking about
> concurrency in terms of threads. (This is completely independent of the
> multi-core Bro effort but rather about general software engineering
> practices in many-core land.)
>
>   

See above :)

>> we'd need to argue about it and potentially find arguments for *not*
>> using it; which will be hard I'm sure. Or somebody might just start
>> using it and "will change that later" ... 
>>     
>
> Fair enough. But at the end of the day we have to make a decision about
> what platform-independent network and I/O framework to use. The Boost
> networking library is of high quality and used widely. If we find a
> slimmer alternative, that would be great.
>   
Just for the record, boost tends to be less of a library and more of a 
label; once a library has existed for long enough at a high enough level 
of quality, it'll often roll itself into boost.  As such, one of the 
libraries bro uses could eventually end up as a piece of boost, at which 
point the team would have to revisit this particular issue.

Just my $0.02.  I guarantee neither relevance nor quality.

--Gilbert