Re: Streams TCP/IP


Guy Harris (gorodish!guy@sun.com)
28 Jul 87 19:18:42 GMT


> 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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:48 GMT