[Bro] effects of &synchronized and &mergeable

David Mandelberg dmandelb at bbn.com
Thu Jan 17 08:50:21 PST 2013


On Tue, 2013-01-15 at 09:39 -0800, Robin Sommer wrote:
> On Mon, Jan 14, 2013 at 17:09 -0500, you wrote:
> >  If a host is in the table and one node deletes it while another node
> >  increments it, is the resulting value always either 0 or 1, or can
> >  the value be old_value + 1?
> 
> Now it's getting tricky and I'm not quite sure off the top of my head,
> but I believe this leads to a race condition and depends on order of
> the operations (per the paper linked to above, we deliberately accept
> race conditions and do a "best effort synchronization").

So if I understand correctly, there's a race condition where some nodes
have 0 and some have 1, but none have old_value + 1, right? I think 0
and 1 are close enough for this application that this should be fine.


>     - in some sense &synchronized is a legacy mechanism. It works and
>       and is supported, but we're moving away from using it. One
>       replacement is the new upcoming "metrics framework", which is a
>       general mechanism to measure/count "stuff". It will have cluster
>       transparency built in that "just works" and should support your
>       counting application nicely. Internally that framework sends
>       evetns around rather than using &synchronized. It's scheduled to
>       be part of Bro 2.2.

Is it usable in a testing environment yet? Is the interface with
external scripts mostly stable? Where do you recommend I start reading
(code or documentation) to learn how to use it?


>     - 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.

It sounds like this is still in design stages, is that right?


>       But that's probably more than you wanted to know. :)

Not at all, thanks for the explanations!





More information about the Bro mailing list