Hi, On Tue, Apr 01, 2008 at 12:45:13PM +0200, Richard Braun wrote:
> In addition, separating the network and transport layers implies > several problems. The most obvious one concerns performance. The Mach > IPC subsystem provides nice virtual copy support, but this facility > creates an important overhead that severely impacts high speed > connections. Carefully shared memory between the servers may help > though. That's why we ultimately want a translator stacking framework (libchannel) for such things. But using that in the network stack is a followup task; first, we need something working at all... > I'd rather suggest having network and transport implementations as > shared object modules. This will help you define the complex interface > between these components. Keep in mind that there are a lot of > protocol specific interactions (e.g. the ICMP implementation interacts > with IP, UDP and TCP to handle redirects, path MTU discovery, closed > ports, etc...). Having a monolithic entity for IPv4/v6 and > TCP/UDP/ICMP (at least) should help you solve interface and > integration probems (of course, once the interface is OK, you can try > moving the implementations in separate translators and experiment, but > this is a (very?) long term step. In that case, there is no point implementing our own stack at all -- we could just as well simply port a newer stack from Linux or BSD or whatever. -antrik-
