On Thu, Dec 14, 2017 at 2:07 PM, Robin Sommer <ro...@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 _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
