get_event_peer() with Broker

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.

Any ideas?

Robin

I was a little concerned that you'd fine something like this. Could we just do what I was suggesting last week where we try to see if we can get rid of the need for that? We don't use the remote peer name for much anyway and I think that it would be good for us if we stopped using it completely.

  .Seth

I was thinking about that but do we really want to give up the ability
to tell where some information is coming from? If nothing else,
wouldn't you want to use it for logging, e.g., to record which Bro
reported a notice? Without that, there's no way to trace something on
the manager back to its source.

Robin

We can just include that information in the notices directly on the worker. There is no reason it needs to be done on the manager.

I think that giving up that information is reasonable and we do it.

  .Seth

Ok, notices were a bad example. :slight_smile:

But, yeah, I hear you. For specific cases, one can always send the
Information explicitly of course. It just doesn't feel great to me to
not have a general way to tell where something is coming from, even
without cooperation from the sender. That's said, we indeed have
hardly any concrete use cases right now, and if you think we don't
need it, I'm fine removing it. The alternative of changing a lot of
code isn't very tempting.

So, then the action item for 2.5 turns into: remove get_event_peer().
I'll do that, and also then still fix is_local_event() to work with
Broker.

Robin

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