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