Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!SPICE.CS.CMU.EDU!Alessandro.Forin From: Alessandro.Forin@SPICE.CS.CMU.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: OS network interfaces (was: sockets vs. streams) Message-ID: <652304954.af@SPICE.CS.CMU.EDU> Date: 2 Sep 90 19:49:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 58 The multiserver Mach 3.0 [and other systems such as Plan9, for instance] place indeed much more semantics in filesystem names. For networking, we have a Network Protocol Server (NP) that contains the protocol code and talks to the ether device (or whatever) at the packet level. It's NP's business what names mean. It's independent of the OS environment (streams, sockets whatever) what is the interface that NP exports to other servers and to the U*x emulation library. [Right now it's just the socket BSD interface, cuz we did it 2 years ago quickly just to see if the thing was plausible] What I am interested in for the second round implementation is what would be the most flexible interface for NP. The goal is to come up with something that can satisfy the needs of multiple OS environments [BSD, sysV, VMS, you name it]. What I have in mind right now is to just be concrete and go with something along the lines of BSD's protocol layer (underneath sockets). This assumes that streams can be made to work on top of it [which is, I gather, exactly what most SysV TCP implementations are]. We (CMU) are not interested in streams or sysV directly, but a number of other people certainly will. Comments and suggestions are therefore extremely welcome. As for extra functionality.. you certainly get to "see" what's going on under /net [default mount point for NP]. If I go by protocols, there are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then /net/ip/tcp /net/ip/udp /net/ip/imp and so on. What's under each protocol is fuzzy, right now, but it will let you see all established connections. As for 'manipulating' things there.. Keith Sklower and others have already pointed out that 'creat' might be messy, but opening an existing file, reading and writing to it (permissions aside) is doable, just like named pipes. [In other words, new names are only created by NP as part of the connection setup] I would pose that /net// loses because a given host can only be reached via some other qualifier besides its 'name': both ether address(es!) and IP numbers are ok, for instance, if you use the right mean. Then again one could overload symlinks to get a different view into the name space. In our system each and every system or user server can export a name space: I can think of the existing named and inetd as simple and useful cases of U*x network servers that can be extended this way. And BTW, all the various databases that go with a server can be administrated in a simpler way by collecting all permanent and temporary information within the server's subtree. Sooo, you have a chance to voice for a bigger-and-better network system .... shoot! sandro- Historical note: We already have a remote filesystem (RFS, it was born long before ma Bell's one) that works along these lines: /../somehost/usr/ is the /usr directory in host's namespace. This is where our own ideas originated.