> On Nov 2, 2017, at 5:54 PM, Siwek, Jon <[email protected]> wrote: > > Thanks, though I’m not sure this scenario maps well to this particular point. > E.g. my impression is Justin wants a single BIF/function that can send one > event from a worker to a proxy and have the proxy purely relay it to all > other workers without doing anything else. So it’s solely taking the cost of > sending N messages from a worker and offloading that burden to a different > node. > > I think your example differs because there is actually an additional > task/logic being performed on the middleman that ends up reducing > comm/processing requirements. i.e. it’s not just a pure relay of messages. > > Or maybe I’m just not understanding what anybody wants :) > > - Jon
I think you're understanding it perfectly :-) You're right that it's often not a pure relay, but it's often the same messaging pattern of "send to all other workers, but deduplicate it first to avoid sending the same message twice back to back". For an example of a purely broadcast use case, see scripts/base/frameworks/intel/cluster.bro You can see the crazy amount of complexity around the Intel::cluster_new_item event. Ultimately what I'm wanting are the messaging patterns to be implemented in something bro ships, so that script writers don't have to implement message broadcasting and relaying themselves - and end up doing it less efficiently than bro can do it internally. Requiring script writers to write cluster and non-cluster versions peppered with @if (Cluster means that bro is not abstracting things at the right level anymore. Maybe with broker data stores there won't be much use for things like event broadcasting, but I feel like anything that does need to be broadcasted should be using an explicit Broadcast function, and not things like manager2worker_events. — Justin Azoff _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
