tirdwr - STREAMS module for reads and writes by TI transport
users
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 [Toc] [Back]
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 [Toc] [Back]
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 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(), 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 generates an
error, and further calls will fail with errno set to
[EPROTO].
Functions: intro(2), getmsg(2), getpmsg(2), putmsg(2),
putpmsg(2), read(2), write(2)
Interfaces: streamio(7)
tirdwr(7)
[ Back ] |
