12 Sep
2018
12 Sep
'18
8:08 a.m.
When I receive events from Bro via Broker, they have the prefix of the
enclosing module:
module Foo;
event foo() { ... }
event bar() { ... }
When I publish "foo" via Broker, it arrives as "Foo::foo". However,
when
I publish an event "Foo::bar" from Broker, Bro doesn't recognize it. I
must published it as "bar" - without the module prefix. Is this
intentional?
Matthias
12 Sep
12 Sep
8:30 a.m.
On Wed, Sep 12, 2018 at 10:09 AM Matthias Vallentin <vallentin(a)icir.org> wrote:
When I receive events from Bro via Broker, they have the prefix of the
enclosing module:
module Foo;
event foo() { ... }
event bar() { ... }
When I publish "foo" via Broker, it arrives as "Foo::foo". However,
when
I publish an event "Foo::bar" from Broker, Bro doesn't recognize it. I
must published it as "bar" - without the module prefix. Is this
intentional?
Maybe not so much intentional, but expected at this point. Does the
suggestion [1] to always explicitly scope events by their
namespace/module address your problem? There's some longstanding
oddities [2] with the way events interact with module namespacing.
- Jon
[1]
https://www.bro.org/sphinx-git/frameworks/broker.html#a-reminder-about-even…
[2] https://bro-tracker.atlassian.net/browse/BIT-71
13 Sep
13 Sep
2:28 a.m.
Does the
suggestion [1] to always explicitly scope events by their
namespace/module address your problem?
That's what I thought would work, but it's the opposite: when I add
the module name as prefix, Bro silently ignores the event. I found a
surprising solution though: if I declare the event first, then it
works. Here's an example:
module Foo;
global foo: event();
event foo() { ... }
This works as expected: when I create an event with name Foo::foo, the
handler gets dispatched. Without the declaration, it doesn't work.
As mentioned in your reference [1], explicit module qualification works as well:
event Foo::foo() { ... }
I'm essentially running into the inverse of BIT-71, the ticket you referenced.
Matthias
10 a.m.
On Thu, Sep 13, 2018 at 4:28 AM Matthias Vallentin <vallentin(a)icir.org> wrote:
So [1] didn't work...
Does the
suggestion [1] to always explicitly scope events by their
namespace/module address your problem?
That's what I thought would work, but it's the opposite: when I add
the module name as prefix, Bro silently ignores the event. As mentioned in your reference [1], explicit module
qualification works as well:
event Foo::foo() { ... }
But [1] also worked? :)
I'm essentially running into the inverse of
BIT-71, the ticket you referenced.
Yeah, I think I see how it's the reverse of the original example, but
it's likely the same underlying module/namespacing ambiguities with
events, so I'd still suggest explicitly scoping events always and
everywhere (which was the [1] suggestion).
It might also help if you send actual examples that can be run if that
still doesn't work because it's hard to interpret what you mean by
"publish via Broker". That could mean Bro's Broker::publish() API or
the standalone Broker API itself and they are potentially different.
I found a
surprising solution though: if I declare the event first, then it
works. Here's an example:
module Foo;
global foo: event();
event foo() { ... }
This works as expected: when I create an event with name Foo::foo, the
handler gets dispatched. Without the declaration, it doesn't work.
Sure, but that's also not the [1] suggestion either. Adding the
namespace scoping always and everywhere means to the event
declaration, the handlers, event/schedule dispatching, any strings
that contain the event name, etc.
- Jon
27 Sep
27 Sep
1:47 a.m.
It might also help if you send actual examples that can
be run if that
still doesn't work because it's hard to interpret what you mean by
"publish via Broker".
Okay, so first a pure Bro example. This one works:
module Foo;
global foo: event(); // declaration
event foo()
{
print "foo";
}
event bro_init()
{
event Foo::foo();
}
If I remove the event declaration, I get:
error in ./foo.bro, line 10: not an event (Foo::foo())
If I remove the Foo:: qualification in bro_init *and* the declaration, I
get the expected output again. If I don't remove the declaration,
nothing gets printed.
Now with Broker, a working example:
redef exit_only_after_terminate = T;
module Foo;
global foo: event(); // declaration
event foo()
{
print "foo";
}
event Broker::peer_added(endpoint: Broker::EndpointInfo, msg: string)
{
Broker::publish("foo", Broker::make_event(foo));
}
event Broker::peer_lost(endpoint: Broker::EndpointInfo, msg: string)
{
terminate();
}
event bro_init()
{
Broker::subscribe("foo");
Broker::peer("localhost", 55555/tcp);
}
The Broker Python script:
#!/usr/bin/env python
import broker
import broker.bro
# Setup endpoint and subscribers.
endpoint = broker.Endpoint()
endpoint.listen("localhost", 55555)
subscriber = endpoint.make_subscriber("foo")
while True:
topic, data = subscriber.get()
print(data)
endpoint.publish("foo", broker.bro.Event("Foo::foo"))
The Python script prints
[<broker._broker.Count object at 0x10ac9f5e0>, <broker._broker.Count object
at 0x10ace2880>, ['Foo::foo', []]]
and the Bro script "foo". So far so good. If I remove the event
declaration, the Python script prints
[<broker._broker.Count object at 0x10ac7c810>, <broker._broker.Count object
at 0x10a04e8b8>, ['foo', []]]
and the Bro script nothing.
I hope this illustrates the issue a bit better.
Matthias
--
Matthias Vallentin
CEO
Tenzir GmbH
c/o Regus
Valentinskamp 24
20354 Hamburg
info(a)tenzir.com
+49 40 209337260
Commercial Register Hamburg
HRB 148081
VAT Number DE314897407
CEOs:
Dr. Matthias Vallentin
Dominik Charousset
4:49 a.m.
On 27/09/2018 10:47, Matthias Vallentin wrote:
If I remove the event declaration, I get:
error in ./foo.bro, line 10: not an event (Foo::foo())
The following works for me:
module Foo;
event Foo::foo()
{
print "foo";
}
event bro_init()
{
event Foo::foo();
}
Just as Jon suggested:
Adding the
namespace scoping always and everywhere means to the event
declaration, the handlers, event/schedule dispatching, any strings
that contain the event name, etc.
Event handlers just don't seem to inherit the surrounding module
namespace, which kind of makes sense if you want to handle events
generated in the global namespace.
Jan
8:27 a.m.
Jan:
Event handlers just don't seem to inherit the
surrounding module
namespace, which kind of makes sense if you want to handle events
generated in the global namespace.
I agree that it does make sense in that regard. It's certainly prudent
- as mentioned - to always qualify your events. The problematic part
that I see is that absence/presence of a forward declaration
interferes with module scoping. This subtlety took me a while to
figure out.
Jon:
[..] so I still suggest the simplest rule/approach
to remember is to always/everywhere prefix event names with an
intended module name.
Yeah, learned that the hard way. ;-)
Matthias
8:12 a.m.
On Thu, Sep 27, 2018 at 3:47 AM Matthias Vallentin <vallentin(a)icir.org> wrote:
I hope this illustrates the issue a bit better.
Thanks, that helps. Underlying issue/pitfall still seems related to
module interactions with event handler definition/declaration, so
added a link back from [#163]. Namely, seems you can try to reason
about events + modules by trying to remember that event declarations
will implicitly get prefixed by module names while event handlers
don't (i.e. a handler for something that hasn't been declared yet
isn't considered an implicit declaration... or at least not the same
kind of declaration). It's not in the scope of Bro 2.6 to try
improving anything here, so I still suggest the simplest rule/approach
to remember is to always/everywhere prefix event names with an
intended module name.
- Jon
[#163] https://github.com/bro/bro/issues/163
933
days inactive
948
days old
7 comments
3 participants
participants (3)
-
Jan Grashöfer -
Jon Siwek -
Matthias Vallentin