[Bro-Dev] [Bro-Commits] [git/broker] topic/actor-system: Add broker::bro::RelayEvent message type. (ce86016)

Jon Siwek jsiwek at corelight.com
Thu Dec 14 13:27:16 PST 2017


On Thu, Dec 14, 2017 at 2:07 PM, Robin Sommer <robin at icir.org> wrote:

> I'm curious what's the use case for this?

>From last month's thread regarding cluster API/topology changes, the
message pattern of sending an event from a worker to all other workers
or proxy/data to all other proxy/data nodes (within these classes,
nodes aren't connected with each other) was frequent enough to warrant
putting in a single, simple function call like this.

e.g. the next thing to come will be adding a function call to do this:

Cluster::relay_round_robin(Cluster::proxy_pool, key,
Cluster::worker_topic, event, event_args);

Which you could use to send an event from a worker to all other
workers via a rotating proxy/data node.  I think at least Justin has
been pushing for something like this.

> Generally I think it's best
> to use a combination of Broker-internal forwarding and topics to
> control where messages get propagated too, as that will better
> generalize to larger topologies later.

At least currently, Bro has the forwarding capability of Broker turned
off.  IIRC, it was very easy to unintentionally create routing loops
when it was turned on and when I asked about it, no one gave any
justification or use-case for it, thus it got turned off.

> The less of the routing we
> control manually at the Bro level, the better I'd say. But that's not
> an absolute rule of course, and I may just be missing what this is
> aiming at.

I'm probably definitely missing some info on long-term plans for
larger topologies and deep-clustering, so let me know if it's
something important to be considering, though it seems like in the
near-term goals and use-cases for the cluster topology, the implicit
routing actually may be more confusing/difficult/error-prone to use
than a simple function call like this which clearly convey's the
sender's intent and expectations.

- Jon


More information about the bro-dev mailing list