tirdwr.4

7号信令功能代码,为开源代码

When a 
.BR read (2),
.BR readv (2),
.BR write "(2) or "
.BR writev (2)
system call fails, it returns -1 and sets
.IR errno (3)
to an appropriate error number as documented on the appropriate manual page.
In addition, tirdwr may return the following errors in response to a
.BR read (2),
.BR readv (2),
.BR write "(2) or "
.BR writev (2):
.TP 12
.RB [ EPROTO ]
The stream user has violoated the read-write protocol.  This error will be
returned on all subsequent read or write operations.  The stream must be
closed and re-opened.
.TP 12
.RB [ ENXIO ]
An attempt was made to write to the stream, however, the transport connection
was disconnected in an unorderly fashion.  All subsequent write operations on
the stream will fail with this error.  Read operations will continue to read
buffered data.  This is similar to the
.RB [ EPIPE ]
error of
.BR pipe (2s).
.\"
.\"
.SH NOTICES
.PP
Any data associated with abortive disconnect
.BR T_DISCON_IND (7)
or orderly release
.BR T_ORDREL_IND (7)
is discarded.  It is unclear whether this is correct behavior or not.
.PP
Due to interaction with the
.BR read "(2), " readv "(2), " write "(2) and " writev (2)
system calls, the priority
forms of the
.BR getmsg "(2), " getpmsg "(2), " putmsg "(2) and " putpmsg (2)
system calls,
and non-zero band form of the
.BR getpmsg "(2) and " putpmsg (2)
system calls,
cannot be used with
.BR tirdwr .
Use of the
.BR putmsg (2)
or
.BR putpmsg (2)
system calls in this fashion will result in an
.RB [ EPROTO ]
error being returned and subsequent failure of all system calls on the stream.
Use of the
.BR getmsg (2)
or
.BR getpmsg (2)
system calls cannot be detected by the module and should be avoided by the
user.
.PP
When system calls
.BR putmsg "(2) and " putpmsg (2)
are used in conjunction with
.BR tirdwr ,
no control part can be specified.
Specification of a control part will result in an
.RB [ EPROTO ]
error and failure of all subsequent system calls on the stream.
When system calls
.BR getmsg "(2) and " getpmsg (2)
are used in conjunction with
.BR tirdwr ,
no control part will be returned.
.\"
.\"
.SH MODULES
.PP
.B tirdwr
.I STREAMS
module.
.\"
.\"
.SH "SEE ALSO"
.PP
.BR T_ORDREL_IND (7),
.BR T_DISCON_IND (7),
.IR errno (3),
.BR write (2),
.BR read (2),
.BR T_OPTDATA_IND (7),
.BR T_DISCON_REQ (7),
.BR xti (3),
.BR writev (2),
.BR tpi (7),
.BR timod (4),
.BR t_open (3),
.BR t_connect (3),
.BR socksys (4),
.BR sockmod (4),
.BR readv (2),
.BR read (2), 
.BR qopen (9),
.BR putpmsg (2),
.BR putmsg (2),
.BR getpmsg (2),
.BR getmsg (2),
.BR T_ORDREL_REQ (7),
.BR T_EXDATA_IND (7),
.BR T_DATA_IND (7).
.\"
.\"
.SH FILES
.PP
.I /lib/modules/\`uname -r\`/streams-timod.o
.\"
.\"
.SH BUGS
.PP
.B tirdwr
has been tested with the
.I /usr/bin/test-tirdwr
conformance test suite.
.PP
.B tirdwr
has no known bugs.
.\"
.\"
.SH COMPATIBILITY
.PP
.B tirdwr
is compatible with
.BR "XNS 5.2"
.[
xns
.]
and
.BR "SVR 4.2" ,
.[
svr42spg
.]
and descriptions for
.BR UnixWare7 \(rg,
.[
uw7doc
.]
.BR AIX \(rg,
.[
aixdoc
.]
.BR DigitalUNIX \(rg,
.[
osfdoc
.]
.BR HP-UX \(rg,
.[
hpuxdoc
.]
.BR Solaris \(rg,
.[
soldoc
.]
.BR SUPER-UX \(rg,
.[
suxdoc
.]
with the following portability considerations:
.PP
This
.B Linux Fast-STREAMS
.[
lfs
.]
implementation of
.B tirdwr
was backported to
.B LiS
.[
LiS
.]
to repair serious bugs in the previous
.B LiS
implementation.
.B LiS
previously had a implementation of
.B tirdwr
that was full of bugs.  This implementation is free of these many bugs and is,
therefore, not compatible with the old buggy
.BR tirdwr .
Following are the bugs exhibited by the old implementation:
.IP \(em \w'\(em\ \ 'u
Zero length data messages, whether they have a control portion or not, are not
supposed to be passed upstream by the
.B tirdwr
module.  This is because a zero-length data message will generate an
end-of-file condition for
.BR read "(2), " readv "(2), " getmsg "(2) and " getpmsg (2).
The
.B tirdwr
module that comes with
.B LiS
.[
lis
.]
passes all
.B M_DATA
and
.BR T_DATA_IND (7)
.B M_DATA
portions upstream without examining them to see if they contain zero-length
data messages.  This is a bug with no work around.
.
When a
.BR T_DISCON_IND (7)
primitive is received by the
.B tirdwr
module, it is supposed to cause all further write system calls
.RB ( write "(2), " writev "(2), " putmsg "(2) and " putpmsg (2))
to fail with error
.RB [ ENXIO ];
however, all read system calls
.RB ( read "(2), " readv "(2), " getmsg "(2) and " getpmsg (2))
system calls are supposed to succeed.
This corresponds to a hungup stream head that has been sent a
.B M_HANGUP
message.
The
.B tirdwr
module that comes with
.B LiS
.[
lis
.]
uses the
.BR putctl1 (9)
form of the
.B M_ERROR
message which causes all system calls to fail with error
.RB [ ENXIO ].
This is a bug with no workaround.
.IP \(em
When the
.B tirdwr
module is pushed on a TI stream, all XTI/TLI library calls are supposed to
fail and return error
.RB [ EPROTO ],
causing all further system calls to fail on the stream.
The
.B tirdwr
module that comes with
.B LiS
.[
lis
.]
passes
.BR M_IOCTL ", " M_IOCDATA ", " M_IOCACK ", " M_IOCNAK ", " M_COPYIN " and " M_COPYOUT
messages transparently, meaning that a number of XTI/TLI functions will not
generate an error.  This is a bug.  A workaround is to refrain from calling
XTI/TLI functions on streams upon which
.B tirdwr
has been pushed.
.IP \(em
When a
.B tirdwr
module receives an
.B M_READ
message from upstream and a
.BR T_ORDREL_IND (7)
has been received and processed for the stream, a zero-length
.B M_DATA
block
or a read size
.B M_ERROR
message should be sent upstream in response to reassert end-of-file and to
keep the reader from blocking indefinitely on read system calls after an
orderly release.
The
.B tirdwr
module that comes with
.B LiS
.[
lis
.]
does not perform this function.  Coupled with passing zero-length data
messages on the read side, this can cause problem with loopback transports and
make it difficult to determine when an end-of-file has actually occurred and
yet not block indefinitely in synchronous file mode.
.IP \(em
When the
.B tirdwr
module is popped (closed) and no
.BR T_ORDREL_IND (7)
or
.BR T_DISCON_IND (7)
has been received for the stream, or if the stream has
encountered an error and has not received a
.BR T_DISCON_IND (7),
the
.B tirdwr
module should send a
.BR T_DISCON_REQ (7)
downstream before completing the close.
The
.B tirdwr
mdoule that comes with
.B LiS
.[
lis
.]
does not send
.BR T_DISCON_REQ (7)
in any circumstance.
The workaround is to always close the stream instead of popping the module
using
.IR I_POP .
.\"
.\"
.SH CONFORMANCE
.PP
.BR SVID ,
.[
svid
.]
.BR XID ,
.[
xbd5
.]
.BR "XNS 5.2" ,
.[
xns
.]
.BR SUSv2 ,
.[
susv2
.]
.BR SUSv3 / POSIX ,
.[
susv3
.]
.\"
.\"
.SH HISTORY
.PP
.B tirdwr
first appeared in
.B SVR 3
.[
svr3
.]
.\"
.\"
.[
$LIST$
.]
.TI