On Fri, Jul 27, 2018 at 7:30 PM Azoff, Justin S <jaz...@illinois.edu> wrote: > > > > On Jul 27, 2018, at 6:10 PM, Jon Siwek <jsi...@corelight.com> wrote: > > > > On Fri, Jul 27, 2018 at 3:55 PM Azoff, Justin S <jaz...@illinois.edu> wrote: > > > >> I do agree that there's room for a lot of simplification, for example a > >> worker broadcasting a message efficiently to all > >> other workers needs to do something like this from the docs: > >> > >> Cluster::relay_rr(Cluster::proxy_pool, "example_key", > >> Cluster::worker_topic, worker_to_workers, > >> Cluster::node + " (via a proxy)"); > >> > >> But a lot of that could have defaults: > >> > >> Most use cases would want to relay through the default proxy pool > >> Since round robin is in use, they key shouldn't matter. > > > > At the moment, one could write their own wrapper function around that > > if they find it too verbose and always want to use certain defaults? > > Yeah.. The wrapper would be trivial.. Should bro include it so that the API > scripts use is simpler?
Maybe. We can see how it fits in the mix of what Robin suggested: # Supports variadic args in place of Broker::Event. Broker::publish(topic: string, args: Broker::Event, relay_topic: string &default="", process_on_relayer: bool &default=F) # Supports variadic args in place of Broker::Event. Cluster::publish(pool: Cluster::pool, key: any, strategy: enum, args: Broker::Event, relay_topic: string &default="", process_on_relayer: bool &default=F) # Supports variadic args in place of Broker::Event. Use proxy pool and RR method w/ arbitrary, internal key by default. Cluster::publish_via_proxy(relay_topic: string, args: Broker::Event) That last one being the wrapper you're asking for. Also, I compressed the ideas of having a separate "relay: bool" / "relay_hops: int" and "relay_topic: string" args -- a non-empty relay topic implicitly means you want to enable relaying on the receiving node. Thinking more about original idea of giving the number of relay hops: it may be better to leave that until Broker multihop is more robust and allow it's automatic forwarding mechanisms to take care of those scenarios whereas a "relay" is a simple mechanism at the Bro application level (has it's own unique message format) that serves to aid load-balancing use-cases (rather than routing use-cases). - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
