STREAMS query

[Guy Harris]

> 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.

Could you please explain how 4.2BSD networking (for which "sockets" is a
poor term - the "socket" code is only the top layer of the 4.2BSD networking
code) is different from V8 networking (for which "streams" may be a poor
term, given that DMR's article described multiplexing as not fitting
strictly within the stream paradigm) in the way you describe?

According to DMR's description, TCP/UDP/IP is implemented in V8 by a big
module - within the kernel.  All the stream buffering is done in the kernel.
What's left that's outside the kernel in V8 but inside the kernel in 4.2BSD?

The main thing that the "socket" layer of the 4.2BSD code provides is common
code to handle what was considered to be the functionality needed by all
communications channels.

I'll agree that it looks like there are a number of things you can do better
with streams than with Berkeley's networking architecture, but it's not
clear that this is a case of two completely different approaches.
Conceivably, one could implement all the Berkeley networking system calls on
top of a streams base.  Would you praise this as enlightened V8 networking
or bash it as unenlightened Berkeley networking?  A lot less
Berkeley/USDL/Bell Labs Research/whoever bashing, and a lot more careful
analysis, would be useful.

	Guy Harris