An Asynchronous Protocol STREAMS Example
In this example, suppose that the computer supports different kinds of asynchronous terminals, each logging in on its own port. The port hardware is limited in function; for example, it detects and reports line and modem status, but does not check parity.
Communications software support for these terminals is provided using a STREAMS-implemented asynchronous protocol. The protocol includes a variety of options that are set when a terminal operator dials in to log on. The options are determined by a getty-type STREAMS user-written process, getstrm, which analyzes data sent to it through a series of dialogs (prompts and responses) between the process and terminal operator.
Note: The getstrm process used in this example is a nonexistent
process. It is not supported by this system.
The process sets the terminal options for the duration of the connection
by pushing modules onto the stream by sending control messages to
cause changes in modules (or in the device driver) already on the
stream. The options supported include:
- ASCII or EBCDIC character codes
- For ASCII code, the parity (odd, even, or none)
- Echoing or no echoing of input characters
- Canonical input and output processing or transparent (raw) character handling
These options are set with the following modules:
| Item | Description |
|---|---|
| CHARPROC | Provides input character-processing functions, including dynamically settable (using control messages passed to the module) character echo and parity checking. The module default settings are meant to echo characters and do not check character parity. |
| CANONPROC | Performs canonical processing on ASCII characters upstream and downstream, this module performs some processing in a different manner from the standard character I/O tty subsystem. |
| ASCEBC | Translates EBCDIC code to ASCII, upstream, and ASCII to EBCDIC, downstream. |
Note: The modules used in this example are nonexistent. They are not
supported by this system.