[Top][All Lists]

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

Re: Hurdish TCP stack (was: updated proposal)

From: Joshua Stratton
Subject: Re: Hurdish TCP stack (was: updated proposal)
Date: Tue, 1 Apr 2008 10:58:29 -0600

Okay, I understand.  I think part of this goes back to a question on the reason for enumeration on these sockets (tcp0, tcp1, etc.) if they aren't used directly in the socket interface for the developer.  I assumed it was as a convenience for other programs that were monitoring the network.  I agree with you that the Plan9 scheme (ex. /dev/net/tcp/123) is the proper way to interface with the network.  With two separate hierarchies, the other one (ex. /dev/eth0/tcp/2) would be a convenience (possibly not a useful one, but it seemed some liked the idea). 


On Tue, Apr 1, 2008 at 9:20 AM, Richard Braun <syn@hurdfr.org> wrote:
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

Version: GnuPG v1.4.1 (GNU/Linux)


reply via email to

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