Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ihnp3.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ihnp3!dhp
From: dhp@ihnp3.UUCP (Douglas H. Price)
Newsgroups: net.unix-wizards,net.lan
Subject: Re: STREAMS query
Message-ID: <169@ihnp3.UUCP>
Date: Mon, 7-Oct-85 16:35:34 EDT
Article-I.D.: ihnp3.169
Posted: Mon Oct  7 16:35:34 1985
Date-Received: Tue, 8-Oct-85 04:12:24 EDT
References: <471@enmasse.UUCP> <1699@brl-tgr.ARPA> <449@cheviot.uucp>
Reply-To: dhp@ihnp3.UUCP (45262-Douglas H. Price)
Distribution: net
Organization: ATT Bell Labs
Lines: 24
Keywords: connection oriented, connectionless messages
Xref: watmath net.unix-wizards:15126 net.lan:1062
Summary: datagrams, no problem

The modality of STREAMs does not preclude datagram services.  STREAMs are
useful as a way for a UNIX process to view a communications device and
a (possibly) associated set of protocols in a device-independent manner.
Let me give you a for-instance:

Lets say you implement a STREAM module that simply guarantees that any
block of data you give it will be transmitted immediately with no guarantee
of safe arrival.  This would be a send-and-pray datagram service, even though
it was implemented in STREAMs.  Lets add a guaranteed end-to-end delivery
service STREAM module, stacked on top of the send-and-pray service.  Now
we have a fast-select datagram service.  Further; lets stack a sequencing and
non-duplication service STREAM module on top of the fast-select service.
Voila, we have a basic virtual circuit. 

There is no requirement that STREAMs must implement a virtual circuit.
That is merely the service that has been discussed most frequently.  Note
also that STREAMs permit a bottom-up definition of just the grade of service
that the application requires.  You don't have to buy the whole nine yards
if you don't want or need it.
-- 
						Douglas H. Price
						Analysts International Corp.
						@ AT&T Bell Laboratories
						..!ihnp4!ihnp3!dhp