> 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. >> If &synchronized is going away script writers should be able to broadcast an >> event to all workers by doing something like >> >> Cluster::Broadcast(Cluster::WORKERS, event Foo(42)); >> >> This would replace a ton of code that currently uses things like >> worker2manager_events+manager2worker_events+@if ( Cluster::local_node_type() >> == Cluster::MANAGER ) > > The successor to &synchronized was primarily intended to be the new data > store stuff, so is there a way to map what you need onto that functionality? > Or can you elaborate on an example where you think this new broadcast pattern > is a better way to replace &synchronized than using a data store? > > - Jon I think a shared data store would work for most of the use cases where people are messing with worker2manager_events. If all the cases of people using worker2manager_events+manager2worker_events to mimic broadcast functionality are really just doing so to update data then it does make sense to just replace all of that with a new data store. How would something like policy/protocols/ssl/validate-certs.bro look with intermediate_cache as a data store? — Justin Azoff _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
