[Bro] effects of &synchronized and &mergeable

David Mandelberg dmandelb at bbn.com
Mon Jan 14 14:09:39 PST 2013


Hi,

I'm trying to write a script to count how many ICMP Destination
Unreachable messages hosts receive. To do that, I'm thinking of using a
table like the below and incrementing the value for each destination
unreachable message.

global icmp_too_many_destination_unreachable_table: table[addr] of count = {}
        &default=0
        &create_expire=icmp_too_many_destination_unreachable_window
        &synchronized
        &mergeable;

I'm a bit unclear about exactly what &synchronized and &mergeable do
though:

Is increment a single atomic operation or is it implemented as multiple
atomic operations (fetch, locally add one, store, return)? I.e. if two
cluster nodes do ++icmp_too_many_destination_unreachable_table[host] at
the same time for the same host, is the value guaranteed to be
incremented twice? Is it guaranteed that the value returned by the two
increments will be different?

If increment is atomic, is it still atomic when incrementing a default
value? I.e., if a host isn't in the table when two nodes simultaneously
increment its count, is the count always properly set to two? 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? Does it matter if the delete is because of &create_expire
or because of an explicit delete?

Is &mergeable necessary in this case? I couldn't figure out from the
documentation if &mergeable applies to the outer table or to its values
if those values are container types.




More information about the Bro mailing list