[Bro-Dev] Improving Bro's main loop

[Robin Sommer]

Nice summary, I agree with all of the pain points. Without thinking
much about solutions yet, a bit of random brainstorming on things to
keep in mind when thinking about this:

    - We need to maintain some predictability in scheduling, in
      particular with regarding to timing/timers. Bro's network time
      time is, by definition, defined through I/O. My gut feeling is
      that we need to keep the tight coupling there, as otherwise
      semantics would change quite a bit.

    - Related, another reason for time playing such an important role
      in the I/O loop is that Bro needs to process its soonest input
      first. That's most important for packet sources: if we have
      packets coming from multiple packet sources, earlier timestamps
      must be processed before later ones across all of them. 

    - Time is generally complex, we have three different notions of
      network time actually, all with some different specifics: time
      during real-time processing, time during offline trace
      processing, and pseudo-realtime.

    - I believe we need to maintain the ability to have I/O loops that
      don't have FDs.

    - I like the idea of using CAF, including because it's going to be
      a required dependency anyways in the future. I would also like
      it conceptually to move I/O to actors, and I'm wondering if even
      packets sources could go there. However, I can't quite tell if
      that's feasible given other constrains and how other parts of
      the system are layed out (including that in the end, everything
      needs to go back into the main thread before being further
      processed; at least for the time being).

    - One of the trickiest parts in the past has been ensuring good
      performance on a variety of platforms and OS versions. Whatever
      we do, it'll be important to do quite a bit of test-driving and
      benchmarking. Let's try to structure the work so that we can get
      to a prototype quickly that allows for some initial performance
      validation of the approach taken.

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin