[Bro-Dev] 'async' update and proposal

[Johanna Amann]

I just wanted to quickly chime in here to say that I generally like the
idea of having these contexts. I have no idea how complex it would be to
implement something like this, but that seems like it might be a
relatively clean solution to our problem :)

Johanna

On Tue, Jan 30, 2018 at 07:38:42AM -0800, Robin Sommer wrote:
> 
> 
> On Mon, Jan 29, 2018 at 13:58 -0600, you wrote:
> 
> >  And if 'function_call' starts as a synchronous function and later
> >  changes, that's also kind of a problem, so you might see people
> >  cautiously implementing the same type of code patterns everywhere
> >  even if not required for some cases.
> 
> That's a good point more generally: if we require "async" at call
> sites, an internal change to a framework can break existing code.
> 
> > event protocol_event_1(c: connection ...) &context = { return c$id; } { ... }
> > 
> > I only skimmed the paper, though seemed like it outlined a similar way
> > of generalizing contexts/scopes ?
> 
> Yeah, that's pretty much the idea there. For concurrency, we'd hash
> that context value and use that to determine a target threat to
> schedule execution too, just like in a cluster the process/machine is
> determined.
> 
> An attribute can work if we're confident that the relevant information
> can always be extracted from the event parameters. In a concurrent
> prototype many years ago we instead used a hardcoded set of choices
> based on the underlying connection triggering the event (5-tuple, host
> pair, src IP, dst IP). So you'd write (iirc):
> 
>     event protocol_event_1(c: connection ...) &scope = connection
> 
> That detaches the context calculation from event parameters, with the
> obvious disadvantage that it can't be customized any further. May be
> there's some middle ground where we'd get both.
> 
> (To clarify terminology: In that paper "scope" is the scheduling
> granularity, e.g., "by connection". "context" is the current
> instantiation of that scope (e.g., "1.2.3.4:1234,2.3.4.5:80" for
> connection scope).
> 
> Robin
> 
> -- 
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>