On Sunday 15 January 2006 12:50, Willem de Bruijn wrote:
> int tcp(char * pkt, int plen){
> if (!ip(pkt, plen))
> return -1;
> //[... process tcp stuff ..]
> return 0;
> }
Linux TCP/IP doesn't work like this.
> Why do people keep developing stream-like architectures, then? First of all,
> streams are not intrinsically slower than sockets. <plug_work>Indeed, the
> system I'm currently finishing of (ffpf) has been shown to outperform linux
> kernel code for filtering
Linux netfilter is basically like STREAMS, so you're just showing
that one STREAM like thing can be faster than another. Undoubtedly
a full hardcoded filter system could be faster.
> Second, some of us believe that with more modular, flexible paths, we can
> reduce code complexity and increase reuse. I'm not too familiar with
> netfilter, but I think it uses a stream-like framework itself.
So you want to replace something that you're not familiar with?
That sounds like a upside down approach. How about studying prior art first
to avoid making their mistakes and reusing their strengths?
> One advantage
> is that a new netfilter function can be inserted in the stream if the module
> is loaded. In a purely functional framework this would be impossible, as all
> functions have to be known in advance.
Your lack of knowledge about netfilter shows very clearly here.
> Lastly, there are uses where reconfigurability is essential. Click had
> routing
> as application domain, where the stream-topology is very dependent on
> administrator policies. Therefore it fitted better than a static functional
> codeblock with many if/then statements.
Have you ever tried reading through the Linux routing code path? It doesn't
sound like it.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
