Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 +MMDF+MULTI+2.11; site uel
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!mcvax!ukc!qtlon!uel!rld
From: rld@uel (Bob Duncanson )
Newsgroups: net.unix-wizards,net.lan
Subject: Re: STREAMS query
Message-ID: <482@uel>
Date: Thu, 10-Oct-85 05:56:43 EDT
Article-I.D.: uel.482
Posted: Thu Oct 10 05:56:43 1985
Date-Received: Mon, 14-Oct-85 03:30:32 EDT
References: <471@enmasse.UUCP> <1699@brl-tgr.ARPA> <449@cheviot.uucp> <2084@amdahl.UUCP>
Organization: Unix Europe Ltd, London UK
Lines: 20
Xref: watmath net.unix-wizards:15218 net.lan:1086

In article <2084@amdahl.UUCP> Stephen Langdon writes:
> The functionality missing in streams (as described in Ritchie's paper),
> is multiplexing.  Without multiplexing you cannot implement kernel resident
> versions of any of the major protocol suites (TCP/IP, OSI, etc.).  If a
> way can be found to add multiplexing to streams, then either connection mode
> or connectionless service should be possible using streams.

I am sure Stephen already knows that streams (as implemented for System V)
does include the capability of multiplexing drivers, and cascading
the connections of such drivers in arbitrary useful (or complex) ways.

I disagree with Santosh Shrivastava (article <499@cheviot.uucp>)
that streams (as is is meant by Ritchie and AT&T) necessarily
implies only connection-oriented in a way that is inferior to sockets.
Connection/non-connection orientation lies in how the mechanism is used
in the same way that there are "stream sockets" and "datagram sockets"
(and "raw sockets").
-- 
Bob Duncanson				{mcvax!ukc!}uel!rld
	Customary Disclaimer of Responsibility applies.