Incomputer networking,STREAMS is the native framework inUnix System V for implementingcharacter device drivers, network protocols, andinter-process communication. In this framework, a stream is a chain ofcoroutines thatpass messages between a program and a device driver (or between a pair of programs). STREAMS originated in Version 8Research Unix, as Streams (not capitalized).
STREAMS's design is a modular architecture for implementing full-duplexI/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.[1] 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.
STREAMS was based on the Streams I/O subsystem introduced in theEighth Edition Research Unix (V8) byDennis Ritchie, where it was used for the terminalI/O subsystem and theInternet 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, andioctl),[2] 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 AT&T NPACK protocol (used inRFS).[3] It was first released with the Network Support Utilities (NSU) package of UNIX System V Release 3.[4] This port added theputmsg,getmsg, andpollsystem calls, which are nearly equivalent in purpose to thesend,recv, andselect calls from Berkeley sockets. Theputmsg andgetmsg system calls were originally calledsend andrecv,[5] but were renamed to avoid namespace conflict.[6] 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 andfile descriptor passing.[3] A port forUNICOS 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".[7]
Concurrent with the System V Release 3 port,AT&T developed protocol-independent STREAMS message passing guidelines for thelink,[8]network,[9] andtransport layers[10] of theOSI model (layers 2-4). Due to the typically close implementation coupling of the network and transport protocols in a givenprotocol stack, and the typical practice of implementing layers 5-7 outside of thekernel, only thelink[8] andtransport layer[11] STREAMS service interfaces were later standardized byX/Open. In conjunction with the transport message passing model, theTransport Layer Interface (later adopted as theX/Open Transport Interface) was defined to provide a transport protocol-independent API for application development. Also, a library supporting thesession,presentation andapplication layers[12] was defined and later standardized byThe Open Group.[13]
STREAMS was required for conformance with theSingle UNIX Specification versions 1 (UNIX 95) and 2 (UNIX 98), but as a result of the refusal of theBSD andLinux developers to provide STREAMS,[citation needed] 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 designated STREAMS as 'marked obsolescent'[14][15] meaning that said functionalitymay be removed in a future version of the specification. However, the specific definition of 'obsolescent' used[16] also says that strictly conforming POSIX applications 'shall not use obsolescent features'.
InVersion 7 Unix, a command was connected to a terminal (keyboard and screen, orkeyboard 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 theReturn 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 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 module chained with aDatakit network module to achieve remote login over a network.[5] Aside from characters (bytes) going from program to device andvice versa, Streams could carry control messages such as "hangup" (drop connection) andioctl messages.
Streams could also be used forinter-process communication, by connecting two processes topseudoterminals. This functionality was implemented in thempx window system for theBlit graphics terminal, which could display multipleterminal 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.[17][18]: 348–350
The actual Streams modules live inkernel space on Unix, and are installed (pushed) and removed (popped) by the ioctl system call. For example, to install the aforementioned line discipline on afile descriptorfd referring to a terminal device, one would write (inC):[18]: 347
ioctl(fd,PUSH,TTYLD);
To perform input/output on a stream, one either uses theread andwrite system calls as with regular file descriptors, or a set of STREAMS-specific functions to send control messages.[19]
Ritchie admitted to regretting having to implement Streams in the kernel, rather than as processes, but felt compelled to do so for reasons of efficiency.[5] A laterPlan 9 implementation did implement modules as user-level processes.[20]
STREAMS has mostly been used in the System V Unix world; however, other implementations exist:
Linux does not include STREAMS functionality without third-party add-ons.Caldera had "pushed" for STREAMS to be included in Linux ca. 1998, to support itsNetware for Linux, but it was rejected outright by the Linux kernel developers on technical grounds (mainly performance).[25] Thecompatibility layers in Linux for other operating systems convert STREAMS operations into sockets as early as possible.[26] The implementation used by Caldera was "LiS", by a company called GCOM; it later figured in thelegal battles by Caldera's successor, theSCO Group, against Linux, with SCO claiming that Linux with STREAMS infringed what it believed to be its copyrights to System V.[25]
putmsg – System Interfaces Reference,The Single UNIX Specification, Version 3 fromThe Open Group, andgetmsg – System Interfaces Reference,The Single UNIX Specification, Version 3 fromThe Open Group.