tirdwr(7)tirdwr(7)NAMEtirdwr - STREAMS module for reads and writes by TI transport users
DESCRIPTION
The tirdwr module is a STREAMS module that provides a transport user
supporting 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 read() and write() functions. It can also continue
to use the putmsg(), putpmsg() and getmsg(), getpmsg() functions, but
these functions will only transfer data messages between the user
process and device stream.
The user places the tirdwr module on a device stream by calling the
STREAMS I_PUSH ioctl() function. 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 errno set to [EPROTO].
The user removes the tirdwr module from a device stream by calling the
STREAMS I_POP ioctl() function.
Module Behavior When Pushed and Popped
When the tirdwr 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 for‐
wards the messages to the user. It ignores any messages related to
process management, such as messages that generate signals to the user.
If any other messages are present, it returns an error to the user
request with errno set to [EPROTO].
When the tirdwr module is popped from a device stream, it checks
whether an orderly release indication has been previously received from
the transport protocol provider. If an orderly release indication was
received, it sends an orderly release request to the remote side of the
transport connection. The tirdwr module also acts this way when the
device stream is closed.
Module Behavior for Reads and Writes
When the tirdwr module receives messages from the transport protocol
provider that do not contain a control part (see the putmsg(),
putpmsg() and getmsg(), getpmsg() 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 neighbor.
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 errno set to [EPROTO]. For messages that represent expedited
data, it generates an error. Further system calls will fail with errno
set to [EPROTO]. For messages that represent an orderly release indi‐
cation from the transport protocol provider, it generates a zero-length
data message, indicating the End-of-File (EOF), and sends this message
upstream to the reading process. The original message containing the
orderly release indication is freed. For messages that represent an
abortive disconnect indication from the transport protocol provider, it
causes all further write() and putmsg(), putpmsg() calls to fail with
errno set to [ENXIO]. Subsequent read() and getmsg(), getpmsg() 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 gen‐
erates an error, and further calls will fail with errno set to
[EPROTO].
SEE ALSO
Functions: intro(2), getmsg(2), getpmsg(2), putmsg(2), putpmsg(2),
read(2), write(2)
Interfaces: streamio(7)tirdwr(7)
