On Thu, Dec 14, 2017 at 15:27 -0600, you wrote:
> 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. Yeah, though then I'd actually say it's worth keeping multi-hop topologies in mind at least. We don't need to fully solve this right now; nobody really knows yet how topologies may end up looking in the future. But a good rule of thumb I think is considering that generally nodes may not be reachable directly, but only through other Broker hops, and that Broker takes care of the routing to get messages there as long as topic subscriptions are set up appropiately. Seems that's actually what we have here already for some nodes. Could we use Broker-level routing here to get connectivity between the nodes that aren't directly connected? > 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. It's off because we indeed don't really have understood yet how to use it. :) But Broker has message TTLs already for detecting loops, and generally I don't think there's anything preventing us from turning it on; it should work. That all said, the priority right now is on getting a basic cluster to work, so no problem doing the relaying as you have it now if that gets us there the quickest. Let's just keep thinking about how such mechanisms will look in the future in other topologies, so that we don't back us into a corner (and I hear your of course: to really do that, we need to understand better where we want to get to). Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev