STREAMS
|
Beyond the STREAMS modules themselves, Gcom® also provides implementations of AT&T compatible STREAMS facility for operating systems that don't include STREAMS as part of the base system. Presently, this enhanced version of the basic STREAMS code is being offered for QNX and Linux. Contents
STREAMS Modules STREAMS ModulesThe STREAMS modules form the core of any STREAMS-based communications project. The modules implement the actual protocols that allow applications to communicate. GCOM provides STREAMS modules for a wide variety of protocols; each has its own features. In general, however, Gcom's modules stand out from others in several ways:
STREAMS FacilitiesMany modern operating systems ship with an implementation of the STREAMS facility already in place. Some, however, don't have this advantage. For two of the operating systems Gcom supports, Gcom has ported the STREAMS facility as a means of rectifying this problem. To make STREAMS even more attractive, Gcom took the opportunity the port presented as a chance to add some extra functionality. These ports emerge with an outstanding feature list:
But Why STREAMS?The introduction of the sockets interface was a boon to network programming. A substantial number of the TCP/IP applications in service today were designed to exploit the simplicity and ease of that interface. The STREAMS interface represents a major rethinking of this popular interface. While STREAMS retains the simplicity of sockets, it also adds significant functionality. For developers of communications applications, it provides two pronounced advantages:
The bottom line is enhanced productivity. By using STREAMS, development teams dramatically shorten development cycles, build products with more flexibility, and improve their ability to address different communications needs. For much more information and a historical perspective, click here. How It WorksWhile most explanations of STREAMS tend to stay fairly quiet about the internals, some understanding of the underlying architecture can be useful. This brief overview should satisfy skeptics, help systems designers make educated purchasing decisions, and give developers some insight into what STREAMS-based applications actually have to work with. One of the most powerful paradigms in data communications is the Open Systems Interconnection model, an ISO recommendation for designing data communications software. This model provides seven distinct layers of protocol, each charged with a certain set of tasks. The diagram identifies these layers.
The STREAMS facility locates the four lowest layers inside the operating system kernel, leaving the upper three layers for user applications to implement. The STREAMS equivalents of the OSI layers are also identified in the diagram. The STREAMS layers are as follows:
A module will use two interfaces: one for upstream traffic and one for downstream traffic. For example, X.25 packet level uses NPI for upstream traffic and DLPI for downstream traffic. STREAMS handles the data flow through these interfaces, connecting the modules into a single data stream with a stream head nestled up against the file system and a physical device connecting the computer to a data line. Typically, a STREAMS module will use a straightforward set of interfaces, communicating with a higher-layer module upstream and a lower-layer module downstream. However, the flexibility of the STREAMS layering system doesn't mandate this. For example, using SNA over an X.25 network is accomplished with a module (QLLC) that uses an NPI interface downstream and a DLPI interface upstream. This layering system will impact development in two places: first, in selecting the appropriate modules to build a protocol stack, and second, in selecting the appropriate interfaces to interact with them. Otherwise, the operation is mostly transparent, due in no small part to the stream head. The stream head is the first stop for all outgoing data and the last stop for incoming data. It nestles up next to the file system, translating the application's manipulations of the STREAMS device's file descriptor into messages for the various STREAMS modules. Original DesignThe original design for what is now STREAMS appeared in a paper by Dennis Ritchie in the October 1984 issue of AT&T Bell Laboratories Technical Journal. |
STREAMS modules provide the mainstay for Gcom's protocol software offerings. These modules work on multiple platforms, in multiple configurations, and with high reliability. Gcom's modules have made many communications projects worldwide into outstanding successes.
