[Bro-Dev] send_id (Re: [Bro-Commits] [git/bro] topic/jsiwek/actor-system: Finish port of control framework to use broker. (8dddae1))

Robin Sommer robin at icir.org
Mon Aug 28 07:59:02 PDT 2017

On Mon, Aug 28, 2017 at 11:09 +0200, you wrote:

> Thanks for the clarification! I was thinking about send_id() in context 
> of the intel framework as well.

Yep, I meant Intel framework of course. :)

> So sending opaque values will still be possible using broker, right?

Yes, correct (one downside of opaque values is that only Bro itself
can send & receive them, for external Broker clients they will remain,
um, opaque :)

> As far as I understand the broker data stores (straight forward 
> key-value stores), a data store does not fit for the intel framework, as 
> it uses e.g. the patricia-trie implementation in tables to efficiently 
> match subnets.

Good point. Support for efficient subnet lookups is something we
should probably add to Broker stores at some point, but that's for the

> 1. Sending all data at once. Maybe ok for that use case.

That would be ok for the new Intel client I think, but sending the
whole thing will put load on the sending Bro as well, which could be a
problem. It depends on the volume of the data of course, it's hard to
say where the limit is.

> 2. Sending stuff incrementally using some script-layer logic.

This might be the best way to go then. In the future I'd like to have
a script-level framework that offers some higher-level communication
patterns on top of Broker, like this one: "send large table safely".
For now, the Intel framework could implement that itself and then
maybe we can even reuse that implementation later by making it more


Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin

More information about the bro-dev mailing list