Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!cica!iuvax!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls
From: dls@mentor.cc.purdue.edu (David L Stevens)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: sockets vs. streams
Message-ID: <13526@mentor.cc.purdue.edu>
Date: 31 Aug 90 21:31:44 GMT
References: <6964@milton.u.washington.edu>
Reply-To: dls@mentor.cc.purdue.edu (David L Stevens)
Organization: PUCC UNIX Group
Lines: 35


	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.

	In Dr Doug Comer's operating system, Xinu, he uses an "open" that
specifies remote address/port names in the "filename" as "XXX.XXX.XXX.XXX:port"
and what would be the mode is instead the local port number, if nonzero. It
works ok, but the name space isn't even pretending to be part of the
filesystem. I don't think I've seen any mapping that makes a lot of sense to
me, though I used to be a NewCastle fan... :-)
	It doesn't surpise me that the socket interface is different, then.
I don't know if that qualifies as the explanation you wanted or not, and
perhaps there are better arguments to be made on both sides...

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)