> On Nov 2, 2017, at 12:58 PM, Azoff, Justin S <[email protected]> wrote:
>
>
>> On Nov 2, 2017, at 1:22 PM, Siwek, Jon <[email protected]> wrote:
>>
>>
>>> On Nov 1, 2017, at 6:11 PM, Azoff, Justin S <[email protected]> wrote:
>>>
>>> - a bif/function for efficiently broadcasting an event to all other workers
>>> (or data nodes)
>>> - If the current node is a data node, just send it to all workers
>>> - otherwise, round robin the event to a data node and have it send it to
>>> all workers minus the current node.
>>
>> In the case of broadcasting from a worker to all other workers, the reason
>> why you relay via another node is only because workers are not connected to
>> each other? Do we know that a fully-connected cluster is a bad idea? i.e.
>> why not have a worker able to broadcast directly to all other workers if
>> that’s what is needed?
>
> Mostly so that workers don't end up spending all their time sending out
> messages when they should be analyzing packets.
Ok, I get what you want to avoid, though could be interesting to actually have
a fully-connected cluster in order to collect performance data on each comm.
pattern and see how significant the difference is for a variety of use-cases.
Do you have a particular example you can give where you’d use this BIF/function
to relay a broadcast from a worker to all other workers via a proxy?
> How would something like policy/protocols/ssl/validate-certs.bro look with
> intermediate_cache as a data store?
global intermediate_store: Cluster::StoreInfo;
event bro_init()
{
intermediate_store =
Cluster::create_store(“ssl/validate-certs/intermediate_store");
}
And then port the rest of that script to use broker data store api
(get/put/exists calls) to access that store.
- Jon
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
