tirdwr.7 (2010 09)

t
tirdwr(7) tirdwr(7)
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 des-
tined 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 mes-
sages 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 indica-
tion 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 mes-
sage 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].
SEE ALSO
getmsg(2), putmsg(2), read(2), write(2), t_open(3), streamio(7), timod(7).
HP-UX 11i Version 3: September 2010 − 1 − Hewlett-Packard Company 1