Re: Hurdish TCP stack

[olafBuddenhagen]

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-