[Bro-Dev] [Bro-Commits] [git/bro] topic/actor-system: First-pass broker-enabled Cluster scripting API + misc. (07ad06b)

[Siwek, Jon]

> On Nov 2, 2017, at 12:58 PM, Azoff, Justin S <jazoff at illinois.edu> wrote:
> 
> 
>> On Nov 2, 2017, at 1:22 PM, Siwek, Jon <jsiwek at illinois.edu> wrote:
>> 
>> 
>>> On Nov 1, 2017, at 6:11 PM, Azoff, Justin S <jazoff at illinois.edu> 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