STREAMS query

[Robert Elz]

In article <455 at basser.oz>, boyd at basser.oz (Boyd Roberts) writes:
> Dead right!  We've got V8. We've used streams. Sockets are totally misguided.
> But, they do fit in well with the berzekeley total confusion implementation
> strategy. Networking in the kernel is all wrong. A sufficent level of support,
> but no more.  This "wired in" gore is just *NOT* the way to go.

Boyd is a little confused - that is, he is confusing sockets & the
network code.

There is no logical reason that sockets require networking code in the
kernel, it just happens to be implemented that way on 4.[23].  Streams
would allow network code to be implemented in the kernel as well.
For example, consider Dennis Ritchie's recent article detailing the
research implementation of tcp/ip using streams - from that I have
no idea at all whether the net protocols are implemented in the
kernel or in user processes.  If you didn't already know how 4.[23]
are implemented, you would not be able to tell from a description
of the socket interface either.

Berkeley decided (from fairly reliable reports) to put the protocol
code in the kernel because they didn't feel that vax context switch
time was fast enough to put it in user mode.  That's an implementation
decision, whether it was correct or not is something that could only
really be answered by someone doing an implementation in user mode.
>From what I've heard of the performance of UNET I'd say they were right
to put it in the kernel, but perhaps a user mode stream implementation
would demonstrate that it can be adequately done that way.

Now the difference (I believe, given limited knowledge of streams,
as most of us just aren't fortunate enough to have ever seen one.
Dennis, if you are reading this, and want to send me the code, I'm
not going to object!) between sockets & streams is that streams
imply names in the filesystem namespace - there has to be something
that you can "open".  Sockets don't have that requirement (I wanted
to say "limitation" but I don't want to appear unnecessarily biased :-).

So, probably misinterpreting from Dennis' article, my guess is that
Dennis' rlogin would be implemented by having rlogin open /dev/tcpNNN
for some NNN, and then doing the regular rlogin protocol (given
that tcp is being done for you somewhere).  The problem is, how
do I find the NNN.  Its possible that this is some kind of magic
device, where two opens of the same name get two completely
different connections, in which case all that would be required
would be that there be one /dev/tcp000 and everyone would use
that.  Is this how its done?  I suspect that its more likely that
rlogin has to hunt for a free /dev/tcpNNN somehow though.  The
question is, why should rlogin care?  It doesn't need to know
any kind of name for its own end of the connection - this is
exactly the abstraction that sockets provide.  With a socket, you
just "make one" (unnamed) then connect to wherever you want to
go (which would also be necessary using the stream approach of
course).

There are other problems than rlogin just having to hunt.  What
if there aren't enough /dev/tcpNNN's for everyone who wants
a connection now?  Just mknod infinity of them?  Seems a little
wasteful.

Conclusion - streams seem to be a great idea, but what I would
like is the socket interface, and then the ability to push
a line discipline (stream?) onto a socket, so I don't need a name
for something I am never going to refer to.

Incidentally, side issue, can someone comment on whether pipes
are implemented using streams in 8th edition unix?  If not,
why not?  The semantics required of a pipe seem to be all
available with streams - deleting the old pipe special cases
would certainly improve the elegance.  (I don't suppose that
I need to say that pipes are implemented using sockets in 4.[23]).

Robert Elz		seismo!munnari!kre	kre%munnari.oz at seismo.css.gov