tirdwr(7)tirdwr(7)NAMEtirdwr - STREAMS module for reads and writes by Transport Interface
users
DESCRIPTION
The module is a STREAMS module that provides a transport user support‐
ing the Transport Interface (TI) with an alternate interface to a
transport protocol provider supporting TI. This alternate interface
allows the transport user to communicate with the transport protocol
provider using the and functions. It can also continue to use the and
functions, but these functions will only transfer data messages between
the user process and device stream. and should not be used with
The user places the module on a device stream by calling the STREAMS
function. is an alternative interface to timod(7). If has been pushed
onto the stream, the user should use the to remove the module from the
stream before pushing The module should only be pushed onto streams
which are terminated by transport providers which conform to the Trans‐
port Interface. Once the module has been pushed on the device stream
the user cannot make further calls to TI functions. If the user
attempts to do this, an error occurs on the stream. After the error is
detected, subsequent calls fail with set to [EPROTO]. The user removes
the module from a device stream by calling the STREAMS function.
Module Behavior When Pushed and Popped
When the module is pushed on a device stream, it checks any existing
messages that are destined for the user to determine their message
type. If existing messages are regular data messages, it forwards the
messages to the user. It ignores any messages related to process man‐
agement, such as messages that generate signals to the user. If any
other messages are present, it returns an error to the user request
with set to [EPROTO].
When the module is popped from a device stream, it checks whether an
orderly release indication has been previously received from the trans‐
port protocol provider. If an orderly release indication was received,
it sends an orderly release request to the remote side of the transport
connection. The module also acts this way when the device stream is
closed.
Module Behavior for Reads and Writes
When the module receives messages from the transport protocol provider
that do not contain a control part (see the putmsg(2) and getmsg(2)
reference pages), it transparently passes the messages to its upstream
neighbor. The exception is for zero-length data messages, where the
module frees the message and does not pass them to its upstream neigh‐
bor.
When the module receives messages from the transport protocol provider
that contain a control part, it takes one of the following actions:
For data messages with a control part, it removes this part,
then passes the message to its upstream neighbor.
For messages that represent expedited data, it generates an
error. Further system calls will fail with set to [EPROTO].
For messages that represent an orderly release indication from
the transport protocol provider, it generates a zero-length data
message, indicating the End-of-File (EOF), and sends this mes‐
sage upstream to the reading process. The original message con‐
taining the orderly release indication is freed.
For messages that represent an abortive disconnect indication
from the transport protocol provider, it causes all further and
calls to fail with set to [ENXIO]. Subsequent and calls will
return zero-length data messages indicating the End-of-File
(EOF), once all previous data has been read.
For all other messages, it generates an error, and further calls
will fail with set to [EPROTO].
SEE ALSOgetmsg(2), putmsg(2), read(2), write(2), t_open(3), streamio(7),
timod(7).
tirdwr(7)
