On 10/08/18 17:12, Robin Sommer wrote: > I hear you, but I think I haven't quite understood the concern yet. > Can you give me an example where the difference matters? What's > different between publishing intel events to bro/cluster/worker/intel > vs bro/cluster/worker if both go to all workers? Or is it so that some > workers can decide not to receive the intel events?
The use case I had in my mind is an external application that is interested in interfacing with the intelligence framework. Either for querying it similar to workers of for managing purposes. If possible, it could be beneficial for such an application to receive only the relevant parts of cluster communication. On 10/08/18 17:52, Jon Siwek wrote: > (1) if the event you're publishing just facilitates scalable cluster > analysis: you'd tend to use the topic names which target node classes > within a cluster (eventually this might be "bro/<cluster-id>/worker") > > (2) if the event you're publishing is intended for external > consumption, then you should use a topic which describes some specific > qualities of the message (e.g. "jan/intel") The case described above seems to be both. On the one hand the primary use case is internal cluster communication. On the other hand it feels quite natural to dock here for external applications. Another (debatable) use case might be directly interfacing the configuration framework, skipping the configuration file layer. Jan _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev