On Fri, Feb 10, 2017 at 11:51 -0600, you wrote:
> What do people think about splitting up portions of init-bare into separate
> files
Yeah, I can see that. It would be nice, though, if init-bare.bro
wouldn't need lots of @load statements then to refer to the individual
files. Maybe we could
On Fri, Feb 10, 2017 at 11:51:08AM -0600, Vlad Grigorescu wrote:
> What do people think about splitting up portions of init-bare into separate
> files, and having init-bare simply @load those files? Right now, it's a
> 4500+ line script that keeps growing, and it commonly results in conflicts.
>
> On Feb 10, 2017, at 11:49 AM, Matthias Vallentin wrote:
>
> Concretely: can you describe (without Bro script code) what "client-side
> load-balancing and failover" means? Who is the client and what state
> needs to be resilient to failure? I don't think we have a working
>
What do people think about splitting up portions of init-bare into separate
files, and having init-bare simply @load those files? Right now, it's a
4500+ line script that keeps growing, and it commonly results in conflicts.
For the protocols, I could see having a file such as
> On Feb 10, 2017, at 9:30 AM, Seth Hall wrote:
>
>
>> On Feb 9, 2017, at 3:21 PM, Azoff, Justin S wrote:
>> # define event and handle on all nodes
>> global scan_attempt: event(scanner: addr, attempt: Attempt);
>> event Scan::scan_attempt(scanner:
> What I want to make possible is client side load balancing and
> failover for worker -> manager/datanode communication.
This is an important part of future Bro deployments.
Before delving into script code, I would like to get a better
understanding of the underlying concepts and communication
On Fri, Feb 10, 2017 at 01:18 +, you wrote:
> if an IOSource needs to poll FDs it can just use poll() in its own
> actor/thread for now
Yeah, one basic decision we'll have to make is how much logic to move
into threads. Conceptually, that's the right thing to do, but we need
to make sure