tp.4

早期freebsd实现

.\" Copyright (c) 1990, 1991, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     @(#)tp.4	8.4 (Berkeley) 4/19/94
.\"
.Dd April 19, 1994
.Dt TP 4
.Os
.Sh NAME
.Nm TP
.Nd
.Tn ISO
Transport Protocol
.Sh SYNOPSIS
.Fd #include <sys/socket.h>
.Fd #include <netiso/iso_errno.h>
.Fd #include <netiso/tp_param.h>
.Fd #include <netiso/tp_user.h>
.Ft int
.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0
.Sh DESCRIPTION
.Pp
The
.Tn TP
protocol provides reliable, flow-controlled, two-way
transmission of data and record boundaries. 
It is a byte-stream protocol and is accessed according to
the
.Dv SOCK_SEQPACKET
abstraction.
The
.Tn TP
protocol makes use of a standard
.Tn ISO
address format,
including a Network Service Access Point, and a Transport Service Entity
Selector.
Subclass 4 may make use of the internet
Internet address format.
.Pp
Sockets utilizing the tp protocol are either
.Dq active
or
.Dq passive .
Active sockets initiate connections to passive
sockets.  By default
.Tn TCP
sockets are created active; to create a
passive socket the
.Xr listen 2
system call must be used
after binding the socket with the
.Xr bind 2
system call.  Only
passive sockets may use the 
.Xr accept 2
call to accept incoming connections.  Only active sockets may
use the
.Xr connect 2
call to initiate connections.
.Pp
Passive sockets may
.Dq underspecify
their location to match
incoming connection requests from multiple networks.  This
technique, termed
.Dq wildcard addressing ,
allows a single
server to provide service to clients on multiple networks.
To create a socket which listens on all networks, the
.Tn NSAP
portion
of the bound address must be void (of length zero).
The Transport Selector may still be specified
at this time; if the port is not specified the system will assign one.
Once a connection has been established the socket's address is
fixed by the peer entity's location.   The address assigned the
socket is the address associated with the network interface
through which packets are being transmitted and received.
.Pp
The
.Tn ISO
Transport Protocol implemented for
.Tn AOS R2
at the University of Wisconsin - Madison,
and modified for inclusion in the Berkeley Software Distribution,
includes classes 0 and 4 
of the
.Tn ISO
transport protocols
as specified in
the June 1986 version of
.Tn IS
8073.
Class 4 of the protocol provides reliable, sequenced,
flow-controlled, two-way
transmission of data packets with an alternate stop-and-wait data path called
the "expedited data" service.
Class 0 is essentially a null transport protocol, which is used
when the underlying network service provides reliable, sequenced,
flow-controlled, two-way data transmission.
Class 0 does not provide the expedited data service.
The protocols are implemented as a single transport layer entity 
that coexists with the Internet protocol suite.
Class 0 may be used only in the
.Tn ISO
domain.
Class 4 may be used in the Internet domain as well as in the
.Tn ISO
domain.
.Pp
Two system calls were modified from the previous
release of the Berkeley Software Distribution
to permit the support of the end-of-transport-service-data-unit
.Pq Dv EOTSDU
indication, and for the receipt and transmission of user
connect, confirm, and disconnect data.
See
.Xr sendmsg 2
and
.Xr recvmsg 2 ,
and further discussion
below for the formats of the data in the ancillary data buffer.
If the
.Dv EOTSDU
is not needed, the normal
.Xr read 2 ,
and
.Xr write 2
system calls may be used.
.Pp
Through the 
.Xr getsockopt
and
.Xr setsockopt
system calls,
.Tn TP
supports several options 
to control such things as negotiable options
in the protocol and protocol strategies.
The options are defined in
.Aq Pa netiso/tp_user.h ,
and are described below.
.Pp
In the tables below,
the options marked with a pound sign
.Ql \&#
may be used 
with
.Xr setsockopt
after a connection is established.
Others must be used before the connection
is established, in other words,
before calling
.Xr connect
or 
.Xr accept .
All options may be used 
with
.Xr getsockopt
before or
after a connection is established.
.Bl -tag -width TPOPT_PSTATISTICS
.It Dv TPOPT_CONN_DATA
(char *) [none]
.br
Data to send on
.Xr connect .
The passive user may issue a
.Xr getsockopt
call to retrieve a connection request's user data,
after having done the
.Xr accept
system call without implying confirmation of the connection.
.Pp
The data may also be retrieved by issuing a
.Xr recvmsg
request for ancillary data only,
without implying confirmation of the connection.
The returned
.Va cmsghdr
will contain
.Dv SOL_TRANSPORT
for the
.Va csmg_level
and
.Dv TPOPT_CONN_DATA
for
.Va cmsg_type.
.It Dv TPOPT_DISC_DATA \&#
(char *) [none]
.br
Data to send on
.Xr close .
Disconnect data may be sent by the side initiating the close
but not by the passive side ("passive" with respect to the closing
of the connection), so there is no need to read disconnect data
after calling
.Xr close .
This may be sent by a
.Xr setsockopt
system call, or by issuing a
.Xr sendmsg
request specifying ancillary data only.
The user-provided
.Va cmsghdr
must contain
.Dv SOL_TRANSPORT
for
.Va csmg_level
and
.Dv TPOPT_DISC_DATA
for
.Va cmsg_type .
Sending of disconnect data will in of itself tear down (or reject)
the connection.
.It Dv TPOPT_CFRM_DATA \&#
(char *) [none]
.br
Data to send when confirming a connection.
This may also be sent by a 
.Xr setsockopt
system call, or by issuing a
.Xr sendmsg
request, as above.
Sending of connect confirm data will cause the connection
to be confirmed rather than rejected.
.It Dv TPOPT_PERF_MEAS \&#
Boolean.
.br
When
.Xr true ,
performance measurements will be kept
for this connection.  
When set before a connection is established, the
active side will use a locally defined parameter on the
connect request packet; if the peer is another
.Tn ARGO
implementation, this will cause performance measurement to be
turned on 
on the passive side as well.
See
.Xr tpperf 8 .
.It Dv TPOPT_PSTATISTICS
No associated value on input.
On output,
.Ar struct tp_pmeas .
.Pp
This command is used to read the performance statistics accumulated
during a connection's lifetime.
It can only be used with
.Xr getsockopt .
The structure it returns is described in
.Aq Pa netiso/tp_stat.h .
See
.Xr tpperf 8 .
.It Dv TPOPT_FLAGS
unsigned integer. [0x0]
.br
This command can only be used with
.Xr getsockopt .
See the description of the flags below.
.It Dv TPOPT_PARAMS
.Ar struct tp_conn_param
.br
Used to get or set a group parameters for a connection.
The
.Ar struct tp_conn_param
is the argument used with the
.Xr getsockopt
or
.Xr setsockopt
system call. 
It is described in 
.Aq Pa netiso/tp_user.h .
.Pp
The fields of the
.Ar tp_conn_param
structure are
described below.
.El
.Pp
.Em Values for TPOPT_PARAMS:
.Bl -tag -width p_sendack_ticks
.It Ar p_Nretrans
nonzero short integer [1]
.br
Number of times a TPDU
will be retransmitted before the
local TP entity closes a connection.
.It Ar p_dr_ticks
nonzero short integer [various]
.br
Number of clock ticks between retransmissions of disconnect request
TPDUs.
.It Ar p_dt_ticks
nonzero short integer [various]
.br
Number of clock ticks between retransmissions of data
TPDUs.
This parameter applies only to class 4.
.It Ar p_cr_ticks
nonzero short integer [various]
.br
Number of clock ticks between retransmissions of connection request
TPDUs.
.It Ar p_cc_ticks
nonzero short integer [various]
.br
Number of clock ticks between retransmissions of connection confirm
TPDUs.
This parameter applies only to class 4.
.It Ar p_x_ticks
nonzero short integer [various]
.br
Number of clock ticks between retransmissions of expedited data
TPDUs.
This parameter applies only to class 4.
.It Ar p_sendack_ticks
nonzero short integer [various]
.br
Number of clock ticks that the local TP entity
will wait before sending an acknowledgment for normal data
(not applicable if the acknowledgement strategy is
.Dv TPACK_EACH ) .
This parameter applies only to class 4.
.It Ar p_ref_ticks
nonzero short integer [various]
.br
Number of clock ticks for which a reference will
be considered frozen after the connection to which
it applied is closed.
This parameter applies to classes 4 and 0 in the 
.Tn ARGO