> On Feb 1, 2016, at 4:45 PM, Robin Sommer <[email protected]> wrote:
>
> I was looking at how to extend the get_event_peer() bif to work with
> Broker events and realized that there's problem I hadn't thought about
> so far: when a event comes into Bro through Broker, there's no way
> right now to tell which peer it was sent from. If I'm not missing
> anything, the event comes only with event name and arguments, but no
> meta information of any kind that would point to its source.
>
> I think adding such meta information would be quite valuable, however
> it's actually not trivial to do that, as it would change the signature
> for incoming events across the whole Broker code base, including
> language bindings etc.
Daniel asked about this a few months ago; not sure if he has any progress to
share, but yeah, code changes would be needed to support that BIF. My
suggested approaches at the time were
1) Change the message format the Bro uses for events. E.g. switch Bro events
from { event_name, { arg1, arg2, arg3 ... } }, to { sender_name, event_name, {
arg2, arg2, arg3 ... } }. Then internally use a lookup table keyed on
sender_name.
2) Change Broker queues to carry a sender/message pair. IIRC a single 32-bit
integer is enough to identify CAF actors, so that means an extra 4 bytes per
message in all queues (since actor-peer mapping can be done locally, those
bytes don’t need to be sent on the wire). You could also have two types of
queues — one type that tracks senders and one type that does not (which is just
the current implementation). Then let the application programmer choose the
best option for individual use cases.
Approach (2) is more robust, but also more work — probably nothing “tricky”,
just hunting down code that needs changing.
- Jon
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
