Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Streams TCP/IP
Message-ID: <24336@sun.uucp>
Date: Tue, 28-Jul-87 15:18:42 EDT
Article-I.D.: sun.24336
Posted: Tue Jul 28 15:18:42 1987
Date-Received: Thu, 30-Jul-87 02:45:19 EDT
References: <725@hjuxa.UUCP> <649@houxa.UUCP> <278@unixprt.UUCP> <561@applix.UUCP> <965@geac.UUCP>
Sender: news@sun.uucp
Lines: 61
Xref: mnetor comp.dcom.lans:695 comp.protocols.tcp-ip:742

>   There is interest in streams for several reasons.
> 	1) It looks elegant.

However, in practice there are some rather inelegant parts.  Doing an
"ioctl" on a stream, for example, is a pain in the neck, as a streams
module or driver is notified of the "ioctl" by receiving a message,
and it must construct a reply message in order to respond to the
"ioctl".

Since streams modules and drivers do not necessarily run in the
context of a process, even when servicing a request made in a process
(e.g., a "write" or an "ioctl"), they cannot block; thus, if a memory
allocation fails, you have to go through some amount of contortions
to retry the allocation if it's important to do so.  Were STREAMS to
be implemented on top of a kernel that supported "lightweight
processes", one could guarantee that streams modules and drivers ran
in the context of a thread of control that could safely block, which
would considerably simplify this.

The read side of a stream is driven by pressure from the bottom;
there is little a streams module or driver can do in response to a
"read".  This may be a problem for some uses of STREAMS.

If you want a STREAMS-based terminal driver, there will be some
problems with sharing a single pool of buffer resources between the
networking code and the terminal driver; it makes it more likely that
networking operations will exhaust these resources.  (RSX-11 users
may remember that - at least in some versions, they may have fixed
this later - a process that consumed all of pool space, or just
sufficient pool space as to prevent the tty driver from doing a read,
could hang the system fairly thoroughly.)  This is not an insuperable
problem, but it means you have to be careful.

When writing a streams module or driver, there is often a lot of
"bureaucratic" code that has to be added to handle various message
types, to construct messages, etc.; don't assume things are going to
get smaller if you go to STREAMS.

> 	2) It comes from an acknowleged Unix expert.

The concept is the same in Dennis Ritchie's version and in the S5R3
version, but some of the details are different.  I believe the S5R3
version is bigger and more complicated.

> 	3) It *looks* (emphais added) more general than sockets.

Since it imposes less structure, it is.  Sockets correspond roughly
to streams+TLI.

> 	4) It allows a structured decomposition of some of the
>   	   hot-spots in Unix (terminal handling, protocols)	
>  	   into subparts which can be placed on a front-end
> 	   processor.

Probably true, although this depends on what the streams modules that
implement a given function are.  It may be that the decomposition
that makes the most architectural sense isn't the decomposition that
makes sense for a particular front-end processor.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com