[Bro-Dev] Broker::publish API
jsiwek at corelight.com
Fri Aug 10 08:52:32 PDT 2018
On Fri, Aug 10, 2018 at 8:29 AM Jan Grashöfer <jan.grashoefer at gmail.com> wrote:
> > Let me try to phrase it differently: If there's already a topic for a
> > use case, it's better to use it. That's easier and less error-prone.
> > So if, e.g., I want to send my script's data to all workers,
> > publishing to bro/cluster/worker will do the job. And that will even
> > automatically adapt if things get more complex later.
> Maybe a silly question: Would that work using further "specialized"
> topics like bro/cluster/worker/intel? From my understanding one feature
> of topics is that one would be able to subscribe only the the things
> that one is interested in. Having a bunch of events just published to
> bro/cluster/worker seems counterproductive.
Yeah, topic use-cases may need clarification. There's one desire to
use topics as a way to specify known destination(s) within a cluster.
Another desire could be using the topic name to hierarchically
summarize/describe a quality of the message content in order to share
with the external world. Maybe the thing that's currently unclear is
what the intended borders are for information sharing? I break it
(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")
Events that fall under (1) don't need to be descriptive since we don't
want to encourage people to arbitrarily start subscribing to events
that act as the details for how cluster analysis is implemented. Or I
guess if they do subscribe, then they are the kind of person that's
more interested in inspecting the cluster's performance/communication
I'd also say that (2) is a user decision -- they need to be the one to
decide if their cluster has produced some bit of information worthy of
sharing to the external world and then publish it under a suitable
That make sense?
More information about the bro-dev