Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

timod(7m) [opensolaris man page]

timod(7M)							  STREAMS Modules							 timod(7M)

NAME
timod - Transport Interface cooperating STREAMS module SYNOPSIS
#include <sys/stropts.h> ioctl(fildes, I_STR, &my_strioctl); DESCRIPTION
timod is a STREAMS module for use with the Transport Interface ("TI") functions of the Network Services library. The timod module converts a set of ioctl(2) calls into STREAMS messages that may be consumed by a transport protocol provider that supports the Transport Interface. This allows a user to initiate certain TI functions as atomic operations. The timod module must be pushed onto only a stream terminated by a transport protocol provider that supports the TI. All STREAMS messages, with the exception of the message types generated from the ioctl commands described below, will be transparently passed to the neighboring module or driver. The messages generated from the following ioctl commands are recognized and processed by the timod module. The format of the ioctl call is: #include <sys/stropts.h> - - struct strioctl my_strioctl; - - strioctl.ic_cmd = cmd; strioctl.ic_timout = INFTIM; strioctl.ic_len = size; strioctl.ic_dp = (char *)buf ioctl(fildes, I_STR, &my_strioctl); On issuance, size is the size of the appropriate TI message to be sent to the transport provider and on return size is the size of the appropriate TI message from the transport provider in response to the issued TI message. buf is a pointer to a buffer large enough to hold the contents of the appropriate TI messages. The TI message types are defined in <sys/tihdr.h>. The possible values for the cmd field are: TI_BIND Bind an address to the underlying transport protocol provider. The message issued to the TI_BIND ioctl is equivalent to the TI message type T_BIND_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI mes- sage type T_BIND_ACK. TI_UNBIND Unbind an address from the underlying transport protocol provider. The message issued to the TI_UNBIND ioctl is equivalent to the TI message type T_UNBIND_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_OK_ACK. TI_GETINFO Get the TI protocol specific information from the transport protocol provider. The message issued to the TI_GETINFO ioctl is equivalent to the TI message type T_INFO_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_INFO_ACK. TI_OPTMGMT Get, set, or negotiate protocol specific options with the transport protocol provider. The message issued to the TI_OPTMGMT ioctl is equivalent to the TI message type T_OPTMGMT_REQ and the message returned by the successful completion of the ioctl is equivalent to the TI message type T_OPTMGMT_ACK. FILES
<sys/timod.h> ioctl definitions <sys/tiuser.h> TLI interface declaration and structure file <sys/tihdr.h> TPI declarations and user-level code <sys/errno.h> system error messages file. Please see errno(3C). SEE ALSO
Intro(3), ioctl(2), errno(3C), tirdwr(7M) STREAMS Programming Guide DIAGNOSTICS
If the ioctl returns with a value greater than 0, the lower 8 bits of the return value will be one of the TI error codes as defined in <sys/tiuser.h>. If the TI error is of type TSYSERR, then the next 8 bits of the return value will contain an error as defined in <sys/errno.h> (see Intro(3)). SunOS 5.11 26 Mar 1993 timod(7M)

Check Out this Related Man Page

tirdwr(7)						 Miscellaneous Information Manual						 tirdwr(7)

NAME
tirdwr - STREAMS module for reads and writes by Transport Interface users DESCRIPTION
The 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 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 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 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 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 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 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 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 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 set to [EPROTO]. For messages that represent an orderly release indication from the transport protocol provider, it generates a zero-length data mes- sage, 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 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 ALSO
getmsg(2), putmsg(2), read(2), write(2), t_open(3), streamio(7), timod(7). tirdwr(7)
Man Page

Featured Tech Videos