STREAMS

From Wikipedia, the free encyclopedia

In computer networking, STREAMS is the native framework in Unix System V for implementing character devices.

STREAMS's design is a modular architecture for implementing full-duplex I/O between kernel or user space processes and between 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.

History

STREAMS was based on the Streams I/O subsystem introduced in the Eighth Edition Research Unix (V8) by Dennis Ritchie, where it was used for the terminal I/O subsystem and the TCP/IP protocol. 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),[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/IP, ISO Class 4 transport, SNA LU 6.2, and the AT&T NPACK protocol (used in RFS).[3] It was first released with the Network Support Utilities (NSU) package of UNIX System V Release 3.[4] This port added the putmsg, getmsg, and poll system calls, which are nearly equivalent to the send, recv, and select calls from Berkeley sockets. The putmsg and getmsg system calls were originally called send and recv,[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 bi-directional pipes and file descriptor passing.[3] 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".[7]

Concurrent with the System V Release 3 port, AT&T developed protocol-independent STREAMS message passing guidelines for the link,[8] network,[9] and transport layers[10] of the OSI model (layers 2-4). Due to the typically close implementation coupling of the network and transport protocols in a given protocol stack, and the typical practice of implementing layers 5-7 outside of the kernel, only the link[8] and transport layer[11] STREAMS service interfaces were later standardized by X/Open. In conjunction with the transport message passing model, the Transport Layer Interface (later adopted as the X/Open Transport Interface) was defined to provide a transport protocol-independent API for application development. Also, a library supporting the session, presentation and application layers[12] was defined and later standardized by The Open Group.[13]

STREAMS was required for conformance with the Single UNIX Specification versions 1 (UNIX 95) and 2 (UNIX 98), but as a result of the refusal of the BSD and Linux developers to provide STREAMS,[citation needed] was marked as optional for POSIX compliance by the Austin Group in version 3 (UNIX 03).

Implementations

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.
  • Mentat wrote an implementation of STREAMS.
    • Novell NetWare utilizes Mentat's STREAMS in its TCP/IP stack.
    • This was licensed by Apple Computer for use in Mac OS starting in version 7.5.2, as part of their Open Transport networking system.
  • The Linux kernel does not include STREAMS functionality. The kernel developers consider it technically inadequate, and the compatibility layers in Linux for other operating systems convert STREAMS operations into sockets as early as possible.[14]
    • LiS (Linux STREAMS) adds STREAMS functionality on Linux[15][16]
    • OpenSS7 offers Fast STREAMS on Linux.[17]
  • FreeBSD has basic support for STREAMS-related system calls, as required by SVR4 binary compatibility layer.
  • The 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,[18][19] by adopting the one from MS LAN Manager for OS/2 1.x.[citation needed]

Notes

  1. ↑ (Goodheart 1994, pp. 51–53,403–527)
  2. ↑ (Goodheart 1994, pp. 52–53)
  3. ↑ 3.0 3.1 (Goodheart 1994, p. 17)
  4. ↑ (Goodheart 1994, p. 51)
  5. ↑ (Ritchie 1984)
  6. ↑ (Goodheart 1994)
  7. ↑ Eric S. Raymond (2003). "Chapter 7. Multiprogramming". The Art of Unix Programming. Addison-Wesley. 
  8. ↑ 8.0 8.1 (DLPI 2.0.0)
  9. ↑ (NPI 2.0.0)
  10. ↑ (TPI 1.5)
  11. ↑ (TPI 2.0.0)
  12. ↑ (APLI 1990)
  13. ↑ (XAP 1993)
  14. ↑ Alan Cox, Streams and Linux, Linux Kernel Mailing List, 28 June 1998
  15. ↑ LiS: Linux STREAMS, Francisco Ballesteros, Linux Journal, Sat 1 May 1999
  16. ↑ LiS home page
  17. ↑ OpenSS7 download page
  18. ↑ (Barr 2001)
  19. ↑ (Valentine 2001)

References

  • Goodheart, Berny; James Cox (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 (XAP)", X/Open CAE Specification (Berkshire, UK: X/Open Company Limited) XAP (c303), ISBN 1-872630-91-X 
  • Pajari, George (1992) [1991], 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, ISBN 0-201-56317-7 
  • Thomas, Rebecca; Lawrence R. Rogers, Jean L. Yates (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, UNIX International Publication (Revision 2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27 
  • UNIX International (August 17, 1992), Network Provider Interface (NPI) Specification, UNIX International Publication (Revision 2.0.0, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27 
  • UNIX International (December 10, 1992), Transport Provider Interface Specification, UNIX International Publication (Revision 1.5, Draft 2 ed.), Parsippany, N.J.: UNIX International Press, retrieved 2009-07-27 
  • UNIX International (October 25, 1990), ACSE/Presentation Library Interface (APLI) Specification, UNIX International Publication (Draft ed.), Parisppany, N.J.: UNIX International Press 
  • Waite Group (1987), Mitchel Waite, ed., UNIX Papers (2nd Printing, 1st ed.), Indianapolis, IN: Howard W. Sams & Company, ISBN 0-672-22578-6 
  • Barr, Adam (June 19, 2001), "Microsoft, TCP/IP, Open Source, and Licensing", Kuro5hin, retrieved February 22, 2013 
  • Valentine, Mark (June 19, 2001). "Re: Query: How to tell if Microsoft is using BSD TCP/IP code?". freebsd-hackers mailing list. http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg24126.html. Retrieved February 22, 2013.

External links

This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.