I'm wondering if we should add another type of plugin component: threads. This would be for functionality that's to run in parallel with Bro's main thread, and communicate with it via message passing.
We have the structure for that in place already, logging and reading are using it as already. But this would formalize the notion a bit more directly that a plugin can provide a new thread, with its own logic; and also extend the interface that it has available from inside that thread (e.g., being able to raise events; have bif functions that, when called, get passed through to the thread). One use case is Christian's OpenFlow plugin: if we went the route of integrating an external library for speaking OpenFlow directly, that communication needs to be handled somewhere. Traditionally, that would be an IOSource hooked into the main loop. The plugin model could support that, too, but being able to fully decouple it inside its own thread seems appealing. Jon, how are you planing to integrate Broker into Bro? Would this help there as well if you could just follow a similar structure with Broker running inside its own thread? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * [email protected] ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
