Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets vs. streams Message-ID: <7880@gollum.twg.com> Date: 3 Sep 90 02:26:19 GMT References: <6964@milton.u.washington.edu> <13526@mentor.cc.purdue.edu> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 85 In article <13526@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes: > > I don't want to get into a religious war, but I don't see where a >filesystem analogy to sockets holds up to any but the most shallow >interpretation. To use your naming, what does it mean if I type: > > cd /tcp//128.210.10.8 >? > What if I do an "ls /tcp"? Be careful-- all of the assigned addresses >aren't available in any one place. Not if NIC.DDN.MIL-- they only have the >network parts... > How do you specify a local address binding when you care? How do you >specify that you don't care? What does a "seek" mean on a socket? How do you >send urgent data in TCP? > In a UNIX implementation, by making the "tcp" a directory, you've >introduced a type of pseudo-device like no other that exists and without >it you lose some of the information you want in the name. > > I won't argue that sockets are the "right" way, and there are certainly >rough edges, but the filesystem analagy *is* artificial. The things you do to >files (ie, storage devices) aren't the things you do with sockets (ie, >communication media). To a degree, you can make the same argument with >terminals, but it doesn't seem to be pushing it quite as much there, to me. My understanding is that some of the filesystem researchers are working towards file systems which one would describe better as "object hierarchies". In this type of system the semantics of objects would vary depending on where you are in the hierarchy. (Part of this could be implemented right now via the "file system switch" stuff in newer Unices.) For the /dev/tcp file system the semantics might be that the next level contains objects whose names are the IP addresses of hosts to which we are currently communicating. Part of the semantics of this level is that it contains (like a directory) objects whose names are the port number of the relavent end of the connection. Objects under /dev/tcp would come and go as connections are created and destroyed. There would be a system call (ioctl()?) for getting/setting various parameters of each end of the connection. It's not too terribly different than stuff currently available within the range of systems that are called Unix. My understanding of the /proc (of v8-v10 and SysVr4 fame) directory is that it acts similarly -- that objects within it appear and disappear as processes come and go. And that ioctl() can get & set various options on the process. And that opening the /proc/nnn `file' (object) lets you read and write the running process. It would probably be a "good thing" for the /dev/tcp objects to have appear under other names than just the IP addresses. After all, people wanna use names to connect to places... so "/dev/tcp/s.ms.uky.edu" would be the same as "/dev/tcp/128.163.128.19", might be implemented as a link(?). There would have to be some code here to do nameserver lookups and set these links up. An internally multitasking OS might be a big help here. Same sort of deal for the next layer down. /dev/tcp/s.ms.uky.edu/smtp for instance. Of course user level applications shouldn't require users to type such nonsense, but should look pretty much like they do now but make translations. You could have a routine that returns a free port. It'd be a simple use of opendir() and readdir() to find the first free one. Oh yeah, opendir() and readdir() type stuff might have to be played with a little bit. But probably not since they get implemented in the kernel nowadays. Just tossing out a few ideas that I've had in my mind for a long time.... Do with them what you will. :-) I don't think there's anything unimplementable, and in fact it would likely work pretty darn well. I would certainly like to see a lot more use made of that file system switch facility. Sun OS v4.1 was a good step in that direction in that it's supporting some pretty funky options/variations to file systems. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!