Dennis Ritchie's motivation when designing "streams" was to replace TTY
line disciplines, because they are incompletely specified, hard to
implement and get right. He never intended that "streams" be used for a
general-purpose networking API as done in System V; that was a raised
middle index finger to the BSD community by the idiots at USG/USL - they
took "streams" and made "STREAMS" (occasionally known as "SEWERS") just to
be different from the sockets API and thereby FUD the UNIX market where
networking was concerned.

In particular, one of the things that "streams" doesn't admit to is the
notion of "datagrams" in the UDP sense of coming and going with totally
random sources and destinations in their headers; "streams" is an
explicitly connection-oriented metaphor (I know this because I asked dmr
about it), where you set up a stream and push protocol modules on its
stack. This was one the areas where the USG/USL idiots had to do serious
violence to "streams" in order to make it work in the general purpose
networking context. I do remember the multiplexing concern you raise, and
have a vague memory of a solution presented in some other paper afterward
by someone in the Bell Labs crowd.

Where I came into the "splice()" discussion was when Chris Demetriou
pointed out that such a system call would not be able to do data transforms
as required by various protocols (e.g. UNIX ASCII to NETASCII for FTP &
SMTP, TELNET byte stuffing, etc), and I suggested "streams" as an answer to
that objection. The model I had in my head was pushing a streams module on
top of one of the file descriptors, and then calling "splice()" to move the
data with the transform. I don't remember if dmr ever generalized the
"streams" model to talk to anything other than devices.

TTY line discplines suck. In fact, the whole TTY interface (including the
USG/USL redesign for "termios") sucks. Messy, with lots of strange state to
keep track of, etc. Ritchie's "streams" was one answer to that situation,
with some very interesting properties.

	Erik <fair@clock.org>