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