+.\" Copyright (c) 1990 The Regents of the University of California.
+.\" All rights reserved.
+.\"
+.\" %sccs.include.redist.man%
+.\"
+.\" @(#)tp.4 6.1 (Berkeley) %G%
+.\"
+.TH TP 4 ""
+.UC 5
+.SH NAME
+.UC 4
+.SH NAME
+TP \- ISO Transport Protocol
+.SH SYNOPSIS
+.nf
+\fB#include <sys/socket.h>\fR
+\fB#include <netiso/iso_errno.h>\fR
+\fB#include <netiso/tp_param.h>\fR
+\fB#include <netiso/tp_user.h>\fR
+.PP
+\fBs = socket( [ AF_INET, AF_ISO ] , SOCK_SEQPACKET, 0);\fR
+.SH DESCRIPTION
+.PP
+The 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 SOCK_SEQPACKET abstraction.
+The TP protocol makes use of a standard 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 \*(lqactive\*(rq or
+\*(lqpassive\*(rq. Active sockets initiate connections to passive
+sockets. By default TCP sockets are created active; to create a
+passive socket the
+.IR listen (2)
+system call must be used
+after binding the socket with the
+.IR bind (2)
+system call. Only
+passive sockets may use the
+.IR accept (2)
+call to accept incoming connections. Only active sockets may
+use the
+.IR connect (2)
+call to initiate connections.
+.PP
+Passive sockets may \*(lqunderspecify\*(rq their location to match
+incoming connection requests from multiple networks. This
+technique, termed \*(lqwildcard addressing\*(rq, allows a single
+server to provide service to clients on multiple networks.
+To create a socket which listens on all networks, the 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 ISO Transport Protocol implemented for AOS R2
+at the University of Wisconsin - Madison,
+and modified for inclusion in the Berkeley Software Distribution,
+includes classes 0 and 4
+of the ISO transport protocols
+as specified in
+the June 1986 version of 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 ISO domain.
+Class 4 may be used in the Internet domain as well as in the ISO domain.
+.PP
+Two system calls were modified from the previous
+release of the Berkeley Software Distribution
+to permit the support the end-of-transport-service-data-unit (EOTSDU)
+indication, and for the receipt and transmission of user
+connect, confirm, and disconnect data.
+See \fIsendmsg(2)\fR and \fIrecmsgv(2)\fR, and further discussion
+below for the formats of the data in the ancillary data buffer.
+If the EOTSDU is not needed, the normal
+.IR read (2),
+and
+.IR write (2)
+system calls may be used.
+.PP
+Through the
+\fIgetsockopt\fR and \fIsetsockopt\fR
+system calls,
+TP supports several options
+to control such things as negotiable options
+in the protocol and protocol strategies.
+The options are defined in \fB<netiso/tp_user.h>\fR,
+and are described below.
+.\".PP
+.\"The options marked with a percent sign ( \fB%\fR )
+.\"are limited to use by the super-user.
+.PP
+In the tables below,
+the options marked with a pound sign ( \fB#\fR )
+may be used
+with \fIsetsockopt()\fR
+after a connection is established.
+Others must be used before the connection
+is established, in other words,
+before calling
+\fIconnect()\fR or
+\fIaccept()\fR.
+All options may be used
+with \fIgetsockopt()\fR
+before or
+after a connection is established.
+.\"
+.\" .PP
+.\" The options marked with an exclamation point ( \fB!\fR )
+.\" may be used after a connection is released,
+.\" but before
+.\" the TP reference timer (which generally
+.\" has a value in minutes) expires, and before
+.\" a \fIclose()\fR system call.
+.\" In other words, these commands may be used when the peer closes
+.\" a connection (possibly causing a disconnect indication), as long as the command
+.\" is issued "soon" after the disconnection occurred.
+.sp 1
+.TP 25
+\fBName\fR
+\fBValue [default]\fR
+.IP
+\fBDescription\fR
+.TP 25
+TPOPT_CONN_DATA
+(char *) [none]
+.IP
+Data to send on \fIconnect()\fR.
+The passive user may issue a
+.IR getsockopt ()
+call to retrieve a connection request's user data,
+after having done the
+.IR accept ()
+system call without implying confirmation of the connection.
+.IP
+The data may also be retrieved by issuing a
+.IR recvmsg ()
+request for ancillary data only,
+without implying confirmation of the connection.
+The returned cmsghdr will contain SOL_TRANSPORT for the csmg_level
+and TPOPT_CONN_DATA for cmsg_type.
+.TP 25
+TPOPT_DISC_DATA\fB #\fR
+(char *) [none]
+.IP
+Data to send on \fIclose()\fR.
+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 \fIclose()\fR.
+This may be sent by a
+.IR setsockopt ()
+system call, or by issuing a
+.IR sendmsg ()
+request specifying ancillary data only.
+The user-provided cmsghdr must contain SOL_TRANSPORT for csmg_level
+and TPOPT_DISC_DATA for cmsg_type.
+Sending of disconnect data will in of itself tear down (or reject)
+the connection.
+.TP 25
+TPOPT_CFRM_DATA\fB #\fR
+(char *) [none]
+.IP
+Data to send when confirming a connection.
+This may aslo be sent by a
+.IR setsockopt ()
+system call, or by issuing a
+.IR sendmsg ()
+request, as above.
+Sending of connect confirm data will cause the connection
+to be confirmed rather than rejected.
+.\".TP 25
+.\"TPOPT_CDDATA_CLEAR\fB #\fR
+.\"No associated value.
+.\".IP
+.\"Erase outgoing connect or disconnect data.
+.TP 25
+TPOPT_PERF_MEAS\fB #\fR
+Boolean.
+.IP
+When \fBtrue\fR, 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 ARGO
+implementation, this will cause performance measurement to be
+turned on
+on the passive side as well.
+See \fItpperf(8)\fR.
+.TP 25
+TPOPT_PSTATISTICS\fB\fR
+No associated value on input.
+On output, struct tp_pmeas.
+.IP
+This command is used to read the performance statistics accumulated
+during a connection's lifetime.
+It can only be used with \fIgetsockopt()\fR.
+The structure it returns is described in \fB<netiso/tp_stat.h>\fR.
+See \fItpperf(8)\fR.
+.TP 25
+TPOPT_FLAGS
+unsigned integer. [ 0x0 ]
+.IP
+This command can only be used with \fIgetsockopt()\fR.
+See the description of the flags below.
+.TP 25
+TPOPT_PARAMS\fB\fR
+struct tp_conn_param.
+.IP
+Used to get or set a group parameters for a connection.
+The struct tp_conn_param is the argument used with the
+\fIgetsockopt()\fR or \fIsetsockopt()\fR system call.
+It is described in
+\fB<netiso/tp_user.h>\fR.
+.PP
+The fields of the \fItp_conn_param\fR structure are
+described below.
+.nf
+.sp 1
+\fIValues for TPOPT_PARAMS:\fR
+.fi
+.TP 25
+\fBField\fR
+\fBValue [default]\fR
+.IP
+\fBDescription\fR
+.\" ******************8
+.TP 25
+p_Nretrans
+nonzero short integer [ 1 ]
+.IP
+Number of times a TPDU will be retransmitted before the
+local TP entity closes a connection.
+.\" ******************8
+.TP 25
+p_dr_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of disconnect request TPDUs.
+.\" ******************8
+.TP 25
+p_dt_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of data TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_cr_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of connection request TPDUs.
+.\" ******************8
+.TP 25
+p_cc_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of connection confirm TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_x_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks between retransmissions of expedited data TPDUs.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_sendack_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks that the local TP entity
+will wait before sending an acknowledgment for normal data
+(not applicable if the acknowlegement strategy is TPACK_EACH).
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_ref_ticks
+nonzero short integer [ various ]
+.IP
+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
+ARGO implementation, despite the fact that
+the frozen reference function is required only for
+class 4.
+.\" ******************8
+.TP 25
+p_inact_ticks
+nonzero short integer [ various ]
+.IP
+Number of clock ticks without an incoming packet from the peer after which
+TP close the connection.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_keepalive_ticks
+nonzero short integer [ various ]
+.IP
+nonzero short integer [ various ]
+Number of clock ticks between acknowledgments that are sent
+to keep an inactive connection open (to prevent the peer's
+inactivity control function from closing the connection).
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_winsize
+short integer between 128 and 16384. [4096 bytes]
+.IP
+The buffer space limits in bytes for incoming and outgoing data.
+There is no way to specify different limits for incoming and outgoing
+paths.
+The actual window size at any time
+during the lifetime of a connection
+is a function of the buffer size limit, the negotiated
+maximum TPDU size, and the
+rate at which the user program receives data.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_tpdusize
+unsigned char between 0x7 and 0xd.
+[ 0xc for class 4 ] [ 0xb for class 0 ]
+.IP
+Log 2 of the maximum TPDU size to be negotiated.
+The TP standard (ISO 8473) gives an upper bound of
+0xd for class 4 and 0xb for class 0.
+The ARGO implementation places upper bounds of
+0xc on class 4 and 0xb on class 0.
+.\" ******************8
+.TP 25
+p_ack_strat
+TPACK_EACH or TPACK_WINDOW. [ TPACK_WINDOW ]
+.IP
+This parameter applies only to class 4.
+Two acknowledgment strategies are supported:
+.IP
+TPACK_EACH means that each data TPDU is acknowledged
+with an AK TPDU.
+.IP
+TPACK_WINDOW
+means that upon receipt of the packet that represents
+the high edge of the last window advertised, and AK TPDU is generated.
+.\" ******************8
+.TP 25
+p_rx_strat
+4 bit mask
+[ TPRX_USE_CW | TPRX_FASTSTART over
+connectionless network protocols ]
+[ TPRX_USE_CW over
+connection-oriented network protocols ]
+.IP
+This parameter applies only to class 4.
+The bit mask may include the following values:
+.IP
+TPRX_EACH: When a retransmission timer expires, retransmit
+each packet in the send window rather than
+just the first unacknowledged packet.
+.IP
+TPRX_USE_CW: Use a "congestion window" strategy borrowed
+from Van Jacobson's congestion window strategy for TCP.
+The congestion window size is set to one whenever
+a retransmission occurs.
+.IP
+TPRX_FASTSTART: Begin sending the maximum amount of data permitted
+by the peer (subject to availability).
+The alternative is to start sending slowly by
+pretending the peer's window is smaller than it is, and letting
+it slowly grow up to the real peer's window size.
+This is to smooth the effect of new connections on a congested network
+by preventing a transport connection from suddenly
+overloading the network with a burst of packets.
+This strategy is also due to Van Jacobson.
+.\" ******************8
+.TP 25
+p_class
+5 bit mask
+[ TP_CLASS_4 | TP_CLASS_0 ]
+.IP
+Bit mask including one or both of the values TP_CLASS_4 and TP_CLASS_0.
+The higher class indicated is the preferred class.
+If only one class is indicated, negotiation will not occur
+during connection establishment.
+.\" ******************8
+.TP 25
+p_xtd_format
+Boolean.
+[ false ]
+.IP
+Boolean indicating that extended format shall be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_xpd_service
+Boolean.
+[ true ]
+.IP
+Boolean indicating that
+the expedited data transport service will be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_use_checksum
+Boolean.
+[ true ]
+.IP
+Boolean indicating the the use of checksums will be negotiated.
+This parameter applies only to class 4.
+.\" ******************8
+.TP 25
+p_use_nxpd
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_use_rcc
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_use_efc
+Reserved for future use.
+.\" ******************8
+.TP 25
+p_no_disc_indications
+Boolean.
+[ false ]
+.IP
+Boolean indicating that the local TP entity shall not issue
+indications (signals) when a TP connection is disconnected.
+.\" ******************8
+.TP 25
+p_dont_change_params
+Boolean.
+[ false ]
+.IP
+If \fBtrue\fR the TP entity will not override
+any of the other values given in this structure.
+If the values cannot be used, the TP entity will drop, disconnect,
+or refuse to establish the connection to which this structure pertains.
+.\" ******************8
+.TP 25
+p_netservice
+One of { ISO_CLNS, ISO_CONS, ISO_COSNS, IN_CLNS }.
+[ ISO_CLNS ]
+.IP
+Indicates which network service is to be used.
+.IP
+ISO_CLNS indicates the connectionless network service provided
+by CLNP (ISO 8473).
+.IP
+ISO_CONS indicates the connection-oriented network service provided
+by X.25 (ISO 8208) and ISO 8878.
+.IP
+ISO_COSNS indicates the
+connectionless network service running over a
+connection-oriented subnetwork service : CLNP (ISO 8473) over X.25 (ISO 8208).
+.IP
+IN_CLNS indicates the
+DARPA Internet connectionless network service provided by IP (RFC 791).
+.\" ******************8
+.TP 25
+p_dummy
+Reserved for future use.
+.sp 1
+.PP
+The TPOPT_FLAGS option is used for obtaining
+various boolean-valued options.
+Its meaning is as follows.
+The bit numbering used is that of the RT PC, which means that bit
+0 is the most significant bit, while bit 8 is the least significant bit.
+.nf
+.sp 1
+\fIValues for TPOPT_FLAGS:\fR
+.fi
+.TP 10
+\fBBits\fR
+\fBDescription [Default]\fR
+.TP 10
+0
+TPFLAG_NLQOS_PDN : set when the quality of the
+network service is
+similar to that of a public data network.
+.TP 10
+1
+TPFLAG_PEER_ON_SAMENET : set when the peer TP entity
+is considered to be on the same network as the local
+TP entity.
+.TP 10
+2
+Not used.
+.TP 10
+3
+TPFLAG_XPD_PRES : set when expedited data are present
+[ 0 ]
+.TP 10
+4..7
+Reserved.
+.\".TP 10
+.\"4
+.\"Reserved.
+.\".TP 10
+.\"5
+.\"TPFLAG_DISC_DATA_IN : read only flag, if set indicates that
+.\"data from a disconnect TPDU are present.
+.\".TP 10
+.\"6
+.\"Reserved.
+.\".TP 10
+.\"7
+.\"TPFLAG_CONN_DATA_IN : read only flag, if set indicates that
+.\"data from a connect TPDU are present.
+.SH "ERROR VALUES
+.PP
+The TP entity returns \fIerrno\fR error values as defined in
+\fB<sys/errno.h>\fR
+and
+\fB<netiso/iso_errno.h>\fR.
+User programs may print messages associated with these value by
+using an expanded version of \fIperror()\fR
+found in the ISO library, \fIlibisodir.a\fR.
+.PP
+If the TP entity encounters asynchronous events
+that will cause a transport connection to be closed,
+such as
+timing out while retransmitting a connect request TPDU,
+or receiving a DR TPDU,
+the TP entity issues a SIGURG signal, indicating that
+disconnection has occurred.
+If the signal is issued during a
+a system call, the system call may be interrupted,
+in which case the
+\fIerrno\fR value upon return from the system call is EINTR.
+If the signal SIGURG
+is being handled by reading
+from the socket, and it was a \fIaccept()\fR that
+timed out, the read may result in ENOTSOCK,
+because the \fIaccept()\fR call had not yet returned a
+legitimate socket descriptor when the signal was handled.
+ETIMEDOUT (or a some other errno value appropriate to the
+type of error) is returned if SIGURG is blocked
+for the duration of the system call.
+A user program should take one of the following approaches:
+.IP "Block SIGURG." 5
+If the program is servicing
+only one connection, it can block or ignore SIGURG during connection
+establishment.
+The advantage of this is that the \fIerrno\fR value
+returned is somewhat meaningful.
+The disadvantage of this is that
+if ignored, disconnection and expedited data indications could be
+missed.
+For some programs this is not a problem.
+.IP "Handle SIGURG." 5
+If the program is servicing more than one connection at a time
+or expedited data may arrive or both, the program may elect to
+service SIGURG.
+It can use the \fIgetsockopt(...TPOPT_FLAGS...)\fR system
+call to see if the signal
+was due to the arrival of expedited data or due to a disconnection.
+In the latter case,
+\fIgetsockopt()\fR
+will return ENOTCONN.
+.SH BUGS
+.PP
+The protocol definition of expedited data is slightly problematic,
+in a way that renders expedited data almost useless,
+if two or more packets of expedited data are send within
+time
+\(*e,
+where \(*e
+depends on the application.
+The problem is not of major significance since most applications
+do not use transport expedited data.
+The problem is this:
+the expedited data acknowledgment TPDU has no field for conveying
+credit, thus it is not possible for a TP entity to inform its peer
+that "I received your expedited data but have no room to receive more."
+The TP entity has the choice of acknowledging receipt of the
+XPD TPDU
+.TP 10
+when the user receives the XPD TSDU
+which may be a fairly long time,
+which may cause the sending TP entity to retransmit the packet,
+and possibly to close the connection after retransmission, or
+.TP 10
+when the TP entity receives it
+so the sending entity does not retransmit or close the connection.
+If the sending user then tries to send more expedited data
+"soon", the expedited data will not be acknowledged (until the
+receiving user receives the first XPD TSDU).
+.PP
+The ARGO implementation acknowledges XPD TPDUs immediately,
+in the hope that most users will not use expedited data requently
+enough for this to be a problem.
+.SH SEE ALSO
+.PP
+tcp(4P),
+netstat(1),
+iso(4F), clnp(4P),
+ifconfig(8).
projects / unix-history / commitdiff