> On Nov 2, 2017, at 12:58 PM, Azoff, Justin S <jaz...@illinois.edu> wrote: > > >> On Nov 2, 2017, at 1:22 PM, Siwek, Jon <jsi...@illinois.edu> wrote: >> >> >>> On Nov 1, 2017, at 6:11 PM, Azoff, Justin S <jaz...@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 _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev