[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurdish TCP stack (was: updated proposal)

From: Richard Braun
Subject: Re: Hurdish TCP stack (was: updated proposal)
Date: Tue, 1 Apr 2008 17:20:54 +0200
User-agent: Mutt/1.5.9i

On Tue, Apr 01, 2008 at 08:07:23AM -0600, Joshua Stratton wrote:
> > It's clearly a mistake to map the directory tree to the protocols stack.
> > The TCP implementation is a global layer, it handles network interfaces
> > internally and must not be bound to any interface (ask yourself how to
> > implement INADDR_ANY, or IPv4 capable IPv6 sockets). 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.
> I'm not sure what you mean  that it's a mistake to map the directory tree to
> the protocol stack.  Do you think the Plan9 implementation, for example, is
> also clearly a mistake then?  I'm not sure if I see the problem.  Wouldn't
> something like INADDR_ANY be a simple hook into the IP layer?  From what I
> understand, a bind on INADDR_ANY locks that port for all interfaces anyway
> so I don't see why this would be a problem.  Just have a special IP binding
> for getting every interface and that connection is shown in every interface
> directory.  Is the problem here with my implementation or a fault you
> generally see in the Plan9 implementation?

/dev/net/tcp/123 is OK. /dev/eth0/tcp/321 isn't. As I said, you must
consider TCP as a global layer, otherwise you will run into name space
conflict problems. For example, a socket in listen mode on INADDR_ANY
is bound to no interface, or all interfaces (at your choice). In the
second case, you should have a unique name for this socket. Having
multiple names like /dev/net/eth0/tcp/1 and /dev/net/eth1/tcp/2 makes
no sense and there are more steps to identify those objects and be sure
they are the same. Making sure the name is unique, i.e. using 123 in all
interface directories is rather complicated for almost no benefit.
Using Plan9 naming scheme, you avoid those problems.

You could have /dev/net/tcp/123/if to obtain the underlying interface of
a socket, using a special string like "any" for unbound sockets.

Richard Braun

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]