Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!decwrl!ucbvax!WORLD.STD.COM!bzs
From: bzs@WORLD.STD.COM (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: sockets vs. streams
Message-ID: <9009012315.AA08202@world.std.com>
Date: 1 Sep 90 23:15:59 GMT
References: <13526@mentor.cc.purdue.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 82


Why does everyone assume this topic is so heated? I think the
discussion is long overdue and we'd all benefit from getting it out in
the open (or is that in in the open()?).

I'm mixed on this issue. TOPS-20 had a file-system-like interface (was
that BBN's TCP?) and, to be frank, I found it quite clumsy (tho
interesting.) The string one passed to the open call started to look
more and more like a long string of IBM/JCL and less and less like a
file name as various options were added.

In MRC's example, the fact that the connection was active or passive
was passed via the flags field (O_CREAT in the example.)

That removes a lot of the utility; I can't specify it on a command
line easily, passing what I want transparently thru a utility that
otherwise doesn't really know it's doing network I/O. That should be a
major goal if we are going to bother at all.

But that leads to things like:

	"/dev/tcp/active/192.74.137.5/143/debug=true/...."

or something like that. I guess one could say "so what, at least you
can do it!" (and, in fact, I don't have a good response to that!)

As to David Stevens questions about file system semantics, what does
"cd /dev/anydev" mean now? Nothing, you get back "Not a directory".
In this mythical TCP you might get back something (e.g. some form of
NFS done this way), or not. I don't see that as a serious problem.

Again, with "ls /tcp" it could be treated like a device, in general
nothing happens (you get back info about just "/tcp".) One could
imagine more being done, but that's an acceptable start.

Seek, urgent data etc, none of that stuff works on every device.

I see you're focusing on the filesystem aspect. It's not that TCP *is*
a filesystem, it's that you can address it with the naming conventions
of the filesystem.

I suppose a counter-argument is why then can't I:

	open("/dev/tty06/9600/cbreak/noecho/xtabs/even/nonl",...)

I dunno, why not?

I'm also not convinced that anything that's happened thus far is
mutually exclusive to a filesystem-like interface. Perhaps it would be
too bad to have two similar interfaces, but that's the worst that
could happen.

In fact, it could be implemented right now. Just write a library with
some of the necessary syscalls written at user-level to recognize
names like this (or if they look like regular files then pass them on
to the kernel) and see how it works. This is kids' stuff, if anyone
wants to know how or doubts it can be done send me mail. You don't
have to touch the kernel to do this (at least not to do a proto.)

On systems with shared libraries it could even be made to work with
existing binaries (tho that can get "exciting", but no big deal if you
have an extra disk to boot off of for experimenting.)

I think there was a project out of Purdue several years ago which did
just this (I forget the name.) I remember playing with some software
from there which did something like this, all user level. Or maybe I
was writing it...hmmm.

My experienced guess is that as one puts it all together all sorts of
problems will arise and it'll tend to get kludgier and kludgier as
more crap is added to that string to make it work.

Maybe I'm wrong, but an experiment is easy enough. I can't see why
someone who was terribly interested wouldn't just demo a prototype and
write a paper for all of us to read (perhaps first verifying that it
hasn't been done a half-dozen times before, possibly reporting where
the disappointments existed.)

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD