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

[Azoff, Justin S]

> On Nov 2, 2017, at 5:54 PM, Siwek, Jon <jsiwek at illinois.edu> 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