Streams vs what?

[Chris Torek]

In article <2515 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
[description of changes to socket interface, relayed from Keith Sklower]
>It certainly didn't involve adding any new system calls.

Well, no and yes.  (heads up seanf :-) )  In fact several `new' syscalls
were added, namely `accept', `bind', `connect', `sendmsg', and `recvmsg'.

What?  You say these already existed?  That is where the `no' part comes
in:  The old versions of the system calls were retained for backwards
compatibility; old binaries continue to run.  The compatibility interface
is slated to vanish in the next BSD (i.e., the one after the forthcoming
release).

I will admit that the basic design of Streams (in which data are passed
back and forth between kernel modules using a uniform interface) is
more elegant than the socket system call interface.  However, the tasks
put upon OSI or TCP streams are just as twisted as those put upon
sockets, and the interface to those tasks is again just as twisted.
The fact is that inter-network communication is ugly, and no one has,
as yet, found the `right' way to make it clean (in the way that
`devices and program-to-program streams [pipes] are files' did for
Unix).  All the problems of connection startup (rendezvous), bit and
byte order and data incompatibility, and protocol goo show through, no
matter whose implementation one uses.  RPC libraries hide the goo
well, but are language (and sometimes even compiler) specific, and
have been inefficient (this concern is, as ever, vanishing under the
tide of hardware improvement and compiler cleverness).

Anyway, BSD may yet get streams, but only the kernel hackers will
really notice.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris