In some email I received from Thor Lancelot Simon, sie wrote:
> On Thu, Oct 25, 2001 at 09:41:39AM +1000, Darren Reed wrote:
> > In some email I received from Perry E. Metzger, sie wrote:
> > > 
> > > Darren Reed <darrenr@reed.wattle.id.au> writes:
> > > > > I don't know about divert sockets, but I see two alternatives:
> > > > > 1) the standard bpf interface  as used e.g. by IDS systems like
> > > > >    snort (it's in pkgsrc)
> > > > 
> > > > divert isn't as lossy as bpf is.
> > > 
> > > Er, at some point any such mechanism will fill its queues. It is just
> > > a question of policy. If you need more buffering because of transient
> > > scheduling issues, you can increase the size of the buffering bpf has
> > > available. If you can't process the packets as fast as they appear, no
> > > amount of buffering will help.
> > > 
> > > Remember, btw, the network itself is lossy.
> > > 
> > > To my mind, bpf is sufficient. Hell, NFR uses it and that's the best IDS
> > > I know.
> > 
> > NFR does not use the same version of BPF as we do.  They optimized it.
> > Can ours be optimized ?  Yes but tcpdump.org doesn't seem too interested.
> 
> We ought to pick up the NFR optimizations.  Really, we should have done so 
> when they initially wrote them.

I don't believe the NFR changes are publicly available - BPF isn't GPL - but
I might be wrong.

Darren