NAME
tirdwr — STREAMS module for reads and writes by Transport Interface 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()
and
getmsg()
functions, but these functions will only transfer data messages between
the user process and device stream.
getpmsg()
and
putpmsg()
should not be used with
tirdwr.
The user places the
tirdwr
module on a device stream by calling the
STREAMS
I_PUSH
ioctl()
function.
tirdwr
is an alternative interface to
timod(7).
If
timod
has been pushed onto the stream, the user should use the
I_POP
ioctl
to remove the
timod
module from the stream before pushing
tirdwr.
The
tirdwr
module should only be pushed onto
streams which are
terminated by transport providers which conform to the Transport
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
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 forwards 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(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 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 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 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()
calls to fail with
errno
set to [ENXIO].
Subsequent
read()
and
getmsg()
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
errno
set to [EPROTO].
Printable version
