[Bro-Dev] 0MQ security considerations
gc355804 at ohio.edu
Wed Jul 27 14:37:54 PDT 2011
>> 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
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:
> 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.
More information about the bro-dev