unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (HP-UX-11.11)
Page:
Section:
Apropos / Subsearch:
optional field



 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 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.




 Hewlett-Packard Company	    - 1 -   HP-UX Release 11i: November 2000






 tirdwr(7)							   tirdwr(7)




      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).

























 Hewlett-Packard Company	    - 2 -   HP-UX Release 11i: November 2000