[Bro-Dev] [Bro] effects of &synchronized and &mergeable

[Robin Sommer]

[Taking to bro-dev]

On Tue, Jan 15, 2013 at 09:39 -0800, I wrote:

>     - we have been kicking around the idea of removing &synchronized
>       completely. it has a number of drawbacks (the loose semantics
>       and race condition; a lack of control for which nodes gets
>       updates) and internally it's very complex to implement. The idea
>       is to replace it with something simpler but more well-defined
>       (like a distributed key-value store) that would be wrapped with
>       script-layer frameworks to provide for easy use.

Seth and I have been mulling over this, and I'd be curious what others
think about this. If we'd remove the &synchronized stuff, we could
throw out a lot of C++-level code and complexity.

A distributed key-value store could probably be implemented simply as
input/output plugins, and with the upcoming sqlite interface we'd get
persistence built in there, too. That generally sounds quite appealing
to me. The main drawback is that I/O capabilities would no longer
directly map to Bro data structures, in particular it's not possible
to keep references within non-atomic data types across the
communication channel. Roughly speaking, we could exchange what we can
currently log, but not more (i.e., no nested records, tables, etc.).
On the other hand we could build script-level frameworks that get some
of that back transparentky by rolling stuff out internally.

We could even go a step further then and send events over that channel
as well. And that in turn might let us eventually remove all the
current communication code and replace with something nicer, maybe
indeed an external library as we've been discussing earlier already.

Robin
 
-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org