.\" $NetBSD: tp.4,v 1.4 1994/11/30 16:22:38 jtc Exp $ .\" .\" 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 .Fd #include .Fd #include .Fd #include .Ft int .Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0 .Sh DESCRIPTION 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 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 implementation, despite the fact that the frozen reference function is required only for class 4. .It Ar p_inact_ticks nonzero short integer [various] .br Number of clock ticks without an incoming packet from the peer after which .Tn TP close the connection. This parameter applies only to class 4. .It Ar p_keepalive_ticks nonzero short integer [various] .br 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. .It Ar p_winsize short integer between 128 and 16384. [4096 bytes] .br 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. .It Ar p_tpdusize unsigned char between 0x7 and 0xd. [0xc for class 4] [0xb for class 0] .br Log 2 of the maximum TPDU size to be negotiated. The .Tn TP standard .Pf ( Tn ISO 8473) gives an upper bound of 0xd for class 4 and 0xb for class 0. The .Tn ARGO implementation places upper bounds of 0xc on class 4 and 0xb on class 0. .It Ar p_ack_strat .Dv TPACK_EACH or .Dv TPACK_WINDOW. .Bq Dv TPACK_WINDOW .br This parameter applies only to class 4. Two acknowledgment strategies are supported: .Pp .Dv TPACK_EACH means that each data TPDU is acknowledged with an AK TPDU. .Pp .Dv TPACK_WINDOW means that upon receipt of the packet that represents the high edge of the last window advertised, an AK TPDU is generated. .It Ar p_rx_strat 4 bit mask .Bq Dv TPRX_USE_CW No \&|\ Dv TPRX_FASTSTART over connectionless network protocols] .Pf [ Dv TPRX_USE_CW over connection-oriented network protocols] .br This parameter applies only to class 4. The bit mask may include the following values: .Pp .Dv TPRX_EACH : When a retransmission timer expires, retransmit each packet in the send window rather than just the first unacknowledged packet. .Pp .Dv 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. .Pp .Dv 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 peer window's real 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. .It Ar p_class 5 bit mask .Bq Dv TP_CLASS_4 No \&|\ Dv TP_CLASS_0 .br Bit mask including one or both of the values .Dv TP_CLASS_4 and .Dv TP_CLASS_0 . The higher class indicated is the preferred class. If only one class is indicated, negotiation will not occur during connection establishment. .It Ar p_xtd_format Boolean. [false] .br Boolean indicating that extended format is negotiated. This parameter applies only to class 4. .It Ar p_xpd_service Boolean. [true] .br Boolean indicating that the expedited data transport service will be negotiated. This parameter applies only to class 4. .It Ar p_use_checksum Boolean. [true] .br Boolean indicating the use of checksums will be negotiated. This parameter applies only to class 4. .It Ar p_use_nxpd Reserved for future use. .It Ar p_use_rcc Reserved for future use. .It Ar p_use_efc Reserved for future use. .It Ar p_no_disc_indications Boolean. [false] .Pp Boolean indicating that the local .Tn TP entity will not issue indications (signals) when a .Tn TP connection is disconnected. .It Ar p_dont_change_params Boolean. [false] .br If .Em true the .Tn TP entity will not override any of the other values given in this structure. If the values cannot be used, the .Tn TP entity will drop, disconnect, or refuse to establish the connection to which this structure pertains. .It Ar p_netservice One of { .Dv ISO_CLNS , .Dv ISO_CONS , .Dv ISO_COSNS , .Dv IN_CLNS } . .Pf [ Dv ISO_CLNS ] .br Indicates which network service is to be used. .Pp .Dv ISO_CLNS indicates the connectionless network service provided by CLNP .Pf ( Tn ISO 8473). .Pp .Dv ISO_CONS indicates the connection-oriented network service provided by X.25 .Pf ( Tn ISO 8208) and .Tn ISO 8878. .Pp .Dv ISO_COSNS indicates the connectionless network service running over a connection-oriented subnetwork service: CLNP .Pf ( Tn ISO 8473) over X.25 .Pf ( Tn ISO 8208). .Pp .Dv IN_CLNS indicates the DARPA Internet connectionless network service provided by IP (RFC 791). .It Ar p_dummy Reserved for future use. .El .Pp The .Dv 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. .sp 1 .Em Values for TPOPT_FLAGS: .Bl -tag -width Bitsx .It Sy Bits .Sy Description [Default] .It \&0 .Dv TPFLAG_NLQOS_PDN : set when the quality of the network service is similar to that of a public data network. .It \&1 .Dv TPFLAG_PEER_ON_SAMENET : set when the peer .Tn TP entity is considered to be on the same network as the local .Tn TP entity. .It \&2 Not used. .It \&3 .Dv TPFLAG_XPD_PRES : set when expedited data are present [0] .It 4\&..7 Reserved. .El .Sh ERROR VALUES The .Tn TP entity returns .Va errno error values as defined in .Aq Pa sys/errno.h and .Aq Pa netiso/iso_errno.h . User programs may print messages associated with these value by using an expanded version of .Xr perror found in the .Tn ISO library, .Pa libisodir.a . .Pp If the .Tn 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 .Tn TP entity issues a .Dv 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 .Va errno value upon return from the system call is .Er EINTR. If the signal .Dv SIGURG is being handled by reading from the socket, and it was an .Xr accept 2 that timed out, the read may result in .Er ENOTSOCK , because the .Xr accept call had not yet returned a legitimate socket descriptor when the signal was handled. .Dv ETIMEDOUT (or a some other errno value appropriate to the type of error) is returned if .Dv SIGURG is blocked for the duration of the system call. A user program should take one of the following approaches: .Bl -tag -width Ds .It Block Dv SIGURG If the program is servicing only one connection, it can block or ignore .Dv SIGURG during connection establishment. The advantage of this is that the .Va errno 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. .It Handle Dv SIGURG 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 .Dv SIGURG . It can use the .Fn getsockopt ...TPOPT_FLAGS... system call to see if the signal was due to the arrival of expedited data or due to a disconnection. In the latter case, .Xr getsockopt will return .Er ENOTCONN . .El .Sh SEE ALSO .Xr tcp 4 , .Xr netstat 1 , .Xr iso 4 , .Xr clnp 4 , .Xr cltp 4 , .Xr ifconfig 8 . .Sh BUGS 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 epsilon, where epsilon 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, so it is not possible for a .Tn TP entity to inform its peer that "I received your expedited data but have no room to receive more." The .Tn TP entity has the choice of acknowledging receipt of the XPD TPDU: .Bl -tag -width Ds .It "when the user receives the" XPD TSDU which may be a fairly long time, which may cause the sending .Tn TP entity to retransmit the packet, and possibly to close the connection after retransmission, or .It "when the" Tn TP No "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 .Dq soon , the expedited data will not be acknowledged (until the receiving user receives the first XPD TSDU). .El .Pp The .Tn ARGO implementation acknowledges XPD TPDUs immediately, in the hope that most users will not use expedited data frequently enough for this to be a problem.