Replies: 4 comments 7 replies
-
I support letting this go, it makes it really hard to understand
what's going. Couples notes:
The replacement would be as follows:
```
# file2.zeek
event http_request(...) {
Broker::publish(manager_topic, myevent);
event myevent();
}
I think it would be nice to still have a way to (explicitly) *forward*
an existing event. That's were `auto_publish()` came from: Zeek B
needs to see (a subset of) what Zeek A sees, like: all http_requests.
Not a must-have, though.
Does anyone have a historic view on `Broker::auto_publish()`? When or why it's useful?
Going back all the way, the original approach to Zeek communication
was to make things as transparent as possible: events and state get
automatically exchanged between Zeeks so that everybody sees the same
(subset of) stuff. However, over time I think it's become pretty clear
that that's not a good model (too much magic) and communication has
become more and more explicit, which is a good thing.
…--
Robin Sommer * Corelight, Inc. * ***@***.*** * www.corelight.com
|
Beta Was this translation helpful? Give feedback.
-
I'd be fine with removing
I don't see how getting rid of # file2.zeek
event http_request(...) {
event myevent(); # implicitly publishes to manager_topic again
}
# file3.zeek
event myevent() {
Broker::publish(manager_topic, myevent);
} That being said, removing
If I remember correctly, using a broadcast topic like |
Beta Was this translation helpful? Give feedback.
-
Past me has some opinions on this subject :-) http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2017-February/012386.html datanodes turned into proxies and In your example where you have
in many cases this would not be the replacement, but instead it would be
because often the event isn't needed on the local process. Much of the current use of
equivalent to
without the user having to use |
Beta Was this translation helpful? Give feedback.
-
I remember a discussion with Robin during the early management framework phase about My sense is that whether to have I think in practice we've long been effectively tightly coupled. Nothing in Zeek clusters naturally comes, goes, fails over, or auto-scales, we have plenty of examples of having built RPCs with eventing, etc. So most of the time, I could see starting by strongly cautioning against the use of |
Beta Was this translation helpful? Give feedback.
-
We're re-visiting pub-sub and the
Broker::auto_publish()
feature came up.It's a thorn in my eye in terms of reasoning which events are published to which remote topics. Basically, using
Broker::auto_publish()
makes publishing events to topics implicit forevent
statements, rather than being explicit through aBroker::publish()
call. TheseBroker::auto_publish()
may be in different places or even different files, so you may never know they exists when looking at a new code base.In conversations with @rsmmr, he didn't sound super fond of it. I heard @JustinAzoff mentioning it makes things complicated, maybe his opinion is stronger. I personally think
Broker::auto_publish()
is an obfuscation tool. Cluster programming is difficult enough, adding some implicit twists make it even harder to reason and review code.A direct replacement of an
event myevent()
would be to explicitly publish it at the same point:The replacement would be as follows:
If an event is published to various topics, then explicit publishes are somewhat less convenient compared to registering multiple auto-publishes for different topics. At the same time, maybe a shared topic for the specific purpose and a single
publish()
invocation would be the better replacement. Here, interested parties would thensubscribe()
to the shared topic, rather than having the producer explicitlypublish()
to the individual topics of interested parties.As an example, we have
Cluster::broadcast_topics
which one couldauto_publish()
orpublish()
individually. The idea would be to have an actualbroadcast_topic = "zeek/cluster/broadcast
which every node type subscribes to and only a singlepublish()
would be required.There's traces of the auto-publish feature within the EventManager, too, which would be nice to rip out :-)
Does anyone have a historic view on
Broker::auto_publish()
? When or why it's useful? I'm not writing a lot of cluster code, but I'm in a fairly opinionated corner where I'd never use it.Beta Was this translation helpful? Give feedback.
All reactions