STREAMS offers two major benefits for applications programmers:
Additional STREAMS features are provided to handle characteristic problems of protocol implementation and to assist in development. There are also kernel- and user-level facilities that support the implementation of advanced functions and allow asynchronous operation of a user process and STREAMS input and output. The following features are discussed:
One benefit of STREAMS is that it simplifies the creation of modules that present a service interface to any neighboring application program, module, or device driver. A service interface is defined at the boundary between two neighbors. In STREAMS, a service interface is a specified set of messages and the rules for allowable sequences of these messages across the boundary. A module that implements a service interface will receive a message from a neighbor and respond with an appropriate action (for example, send back a request to retransmit) based on the specific message received and the preceding sequence of messages.
STREAMS provides features that make it easier to design various application processes and modules to common service interfaces. If these modules are written to comply with industry-standard service interfaces, they are called protocol modules.
In general, any two modules can be connected anywhere in a stream. However, rational sequences are generally constructed by connecting modules with compatible protocol service interfaces.
STREAMS provides the capabilities to manipulate modules from user level, to interchange modules with common service interfaces, and to present a service interface to a stream user process. These capabilities yield benefits when implementing networking services and protocols, including:
Examples of the benefits of STREAMS capabilities to developers for creating service interfaces and manipulating modules are:
Alternative protocol modules (and device drivers) can be interchanged on the same machine if they are implemented to equivalent service interfaces.
The Module Reusability Diagram shows the same canonical module (for example, one that provides delete and kill processing on character strings) reused in two different streams. This module typically is implemented as a filter, with no downstream service interface. In both cases, a tty interface is presented to the stream user process since the module is nearest the stream head.
