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).
Thanks, Josh On Tue, Apr 1, 2008 at 9:20 AM, Richard Braun <[EMAIL PROTECTED]> 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFH8lLWBlWsEPLYRi8RAgcuAJ4s1iOh3s3FHSXq5HxpPn8i3JKI2ACfTfhS > x9zyMT27Q2lEuTD2QPg85+U= > =X7/K > -----END PGP SIGNATURE----- > >
