[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