[Bro-Dev] get_event_peer() with Broker

Siwek, Jon jsiwek at illinois.edu
Fri Feb 5 08:19:01 PST 2016


> On Feb 1, 2016, at 4:45 PM, Robin Sommer <robin at icir.org> 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



More information about the bro-dev mailing list