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 future. > 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 generic. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
