In computer networking ,
STREAMS is the native framework in Unix
System V for implementing character device drivers, network protocols,
and inter-process communication . In this framework, a stream is a
chain of coroutines that pass messages between a program and a device
driver (or between a pair of programs).
STREAMS originated in Version
Research Unix , as Streams (not capitalized).
STREAMS's design is a modular architecture for implementing
full-duplex I/O between kernel and device drivers. Its most frequent
uses have been in developing terminal I/O (line discipline ) and
networking subsystems. In System V Release 4, the entire terminal
interface was reimplemented using STREAMS. An important concept in
STREAMS is the ability to push drivers – custom code modules which
can modify the functionality of a network interface or other device
– together to form a stack. Several of these drivers can be chained
together in order.
* 1 History
* 2 Technical overview
* 3 Implementations
* 4 Notes
* 5 References
* 6 External links
STREAMS was based on the Streams I/O subsystem introduced in the
Research Unix (V8) by
Dennis Ritchie , where it was
used for the terminal I/O subsystem and the
Internet protocol suite .
This version, not yet called
STREAMS in capitals, fit the new
functionality under the existing device I/O system calls (open, close,
read, write, and ioctl), and its application was limited to terminal
I/O and protocols providing pipe-like I/O semantics.
This I/O system was ported to System V Release 3 by Robert Israel,
Gil McGrath, Dave Olander, Her-Daw Che, and Maury Bach as part of a
wider framework intended to support a variety of transport protocols,
including TCP, ISO Class 4 transport, SNA LU 6.2, and the
protocol (used in RFS ). It was first released with the Network
Support Utilities (NSU) package of
UNIX System V Release 3. This port
added the putmsg, getmsg, and poll system calls , which are nearly
equivalent in purpose to the send, recv, and select calls from
Berkeley sockets. The putmsg and getmsg system calls were originally
called send and recv, but were renamed to avoid namespace conflict.
In System V Release 4,
STREAMS was extended and used for the terminal
I/O framework and pipes, providing useful new functionality like
bidirectional pipes and file descriptor passing. A port for Unicos
was also produced.
Eric S. Raymond quotes Ritchie as saying about the
complexity of System V
STREAMS when compared to his V8 Streams that
"Streams means something different when shouted".
Concurrent with the System V Release 3 port, AT"> was marked as
optional for POSIX compliance by the Austin Group in version 3 (UNIX
03). POSIX.1-2008 with TC1 (IEEE Std 1003.1, 2013 edition) has
STREAMS as 'marked obsolescent' meaning that said
functionality may be removed in a future version of the specification.
However, the specific definition of 'obsolescent' used also says that
strictly conforming POSIX applications 'shall not use obsolescent
Example use of Streams to implement remote command execution
over a network, after (Ritchie 1984 )
Version 7 Unix , a command was connected to a terminal (keyboard
and screen, or keyboard and printer ) through a mechanism called the
line discipline, which would buffer a single line of input, i.e., wait
for the user to press the
Return key before sending input to the
program for processing; this allowed simple error correction. Streams
replaced this with a set of processing modules organized in a linear
chain that allowed bidirectional communication with between
neighboring modules. Programs could "push" a new module onto one end
of the chain to change the behavior of a terminal or other character
device. Ritchie gives the example chain of a terminal modules chained
Datakit network module to achieve remote login over a network.
Aside from characters (bytes) going from program to device and vice
versa, Streams could carry control messages such as "hangup" (drop
connection) and ioctl messages.
Streams could also be used for inter-process communication , by
connecting two processes to pseudoterminals . This possibility was in
the mpx window system for the Blit graphics terminal, which could
display multiple terminal emulator windows. Each window was a process
that communicated with the window system through a pseudoterminal that
had the line discipline driver installed, sending typed characters to
it and receiving text (and graphics) to display. Control signals
designated the user's wish to switch between windows or close them.
The actual Streams modules lives in kernel space on Unix, and are
installed (pushed) and removed (popped) by the ioctl system call. For
example, to install the aforementioned line discipline on a file
descriptor fd referring to a terminal device, one would write (in C ):
ioctl(fd, PUSH, TTYLD);
To perform input/output on a stream, one either uses the read and
write system calls as with regular file descriptors, or a set of
STREAMS-specific functions to send control messages.
Ritchie admitted to regretting having to implement Streams in the
kernel, rather than as processes, but felt compelled to do for reasons
of efficiency. A later Plan 9 implementation did implement modules as
STREAMS has mostly been used in the System V Unix world; however,
other implementations exist:
* Plan 9 originally used a multi-processor variant of Research
Unix's Streams. During the transition to the third edition of Plan 9,
Streams were further simplified to simple I/O queues.
* An implementation written at Mentat was used in
its TCP/IP stack, and licensed by Apple for use in the classic Mac OS
starting in version 7.5.2, as part of the
Open Transport networking
system. (In macOS , the
Classic Environment used the STREAMS
architecture, but the native networking architecture uses the Berkeley
sockets API and is derived from the
BSD networking code.)
BSD has basic support for STREAMS-related system calls, as
required by SVR4 binary compatibility layer.
Windows NT kernel offered a full port of
STREAMS as the
streams.sys binary. NT DDK even had a chapter on STREAMS, going as
late as NT4 though in NT4 DDK it was declared obsolete. The original
TCP/IP stack for
Windows NT 3.1 was implemented atop
STREAMS by Spider
Systems , and used the streams.sys binary. From NT 3.5 up, TCP/IP was
remade completely, by adopting the one from MS LAN Manager for OS/2
Linux does not include
STREAMS functionality without third-party
add-ons. Caldera had "pushed" for
STREAMS to be included in
1998, to support its Netware for
Linux , but it was rejected outright
Linux kernel developers on technical grounds (mainly
performance). The compatibility layers in
Linux for other operating
STREAMS operations into sockets as early as possible.
The implementation used by Caldera was "LiS", by a company called
GCOM; it later figured in the legal battles by Caldera's successor,
SCO Group , against Linux, with SCO claiming that
STREAMS infringed what it believed to be its copyrights to System V.
* ^ (Goodheart 1994 , pp. 51–53,403–527)
* ^ (Goodheart 1994 , pp. 52–53)
* ^ A B (Goodheart 1994 , p. 17)
* ^ (Goodheart 1994 , p. 51)
* ^ A B C (Ritchie 1984 )
* ^ (Goodheart 1994 )
Eric S. Raymond (2003). "Chapter 7. Multiprogramming". The Art
of Unix Programming . Addison-Wesley.
* ^ A B (DLPI & 2.0.0 )
* ^ (NPI & 2.0.0 )
* ^ (TPI & 1.5 )
* ^ (TPI & 2.0.0 )
* ^ (APLI 1990 )
* ^ (XAP 1993 )
* ^ "Base Specifications, Issue 7, 2013 Edition, Section B.2.6
STREAMS". The Open Group. Retrieved 9 March 2015.
* ^ "The Austin Common Standards Revision Group". The Open Group.
Retrieved 9 March 2015.
* ^ "
The Open Group Base Specifications Issue 7, Codes". The Open
Group. Retrieved 9 March 2015.
* ^ Pike, Rob (1984). "The Blit: A Multiplexed Graphics Terminal".
AT&T Bell Laboratories Technical Journal. 63 (8): 1607–1631.
* ^ A B Bach, Maurice J. (1986). The Design of the UNIX Operating
System. Prentice Hall.
* ^ See: putmsg – System Interfaces Reference, The Single UNIX®
Specification , Issue 6 from
The Open Group , and getmsg – System
Interfaces Reference, The Single UNIX® Specification , Issue 6 from
The Open Group .
* ^ A B Presotto, David L. (1990). Multiprocessor streams for Plan
9. Proc. UKUUG Summer Conf.
CiteSeerX 10.1.1.42.1172 .
* ^ (Barr 2001 )
* ^ (Valentine 2001 )
* ^ A B "STREAMS, LiS, and Caldera\'s Netware for
Linux - Updated".
Groklaw . 3 July 2006. Retrieved 27 December 2014.
* ^ Alan Cox, Streams and Linux,
Linux Kernel Mailing List, 28 June
* Goodheart, Berny; Cox, James (1994), The magic garden explained:
the internals of
UNIX System V Release 4, an open-systems design,
Australia: Prentice Hall, ISBN 0-13-098138-9
* Open Group (1999), "Transport Provider Interface (TPI)
Specification", Open Group CAE Specification (Revision 2.0.0, Draft 2
ed.), Berkshire, UK: Open Group Publication
* Open Group (September 1993), "ACSE/Presentation Services API
X/Open CAE Specification, Berkshire, UK:
Limited, XAP (c303), ISBN 1-872630-91-X
* Pajari, George (1992) , Writing UNIX Device Drivers (2nd Printing,
1st ed.), Reading, MA: Addison-Wesley, ISBN 0-201-52374-4
* Ritchie, Dennis M. (October 1984). "A Stream Input-Output System".
AT&T Bell Laboratories Technical Journal 63, No. 8 Part 2. AT&T:
1897–1910. Retrieved 2006-05-19.
* Stevens, W. Richard (1993), Advanced Programming in the UNIX
Environment (15th Printing, 1st ed.), Reading, MA: Addison-Wesley,
* Thomas, Rebecca; Rogers, Lawrence R.; Yates, Jean L. (1986),
Advanced Programmers Guide to UNIX System V, Berkeley, CA: Osborne
McGraw-Hill, ISBN 0-07-881211-9
* UNIX International (August 20, 1991), Data Link Provider Interface
(DLPI) Specification (PDF), UNIX International Publication (Revision
2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press,
* UNIX International (August 17, 1992), Network Provider Interface
(NPI) Specification (PDF), UNIX International Publication (Revision
2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press,
* UNIX International (Decemb