4.4BSD/usr/share/man/cat4/tp.0
TP(4) BSD Programmer's Manual TP(4)
NNAAMMEE
TTPP - ISO Transport Protocol
SSYYNNOOPPSSIISS
##iinncclluuddee <<ssyyss//ssoocckkeett..hh>>
##iinncclluuddee <<nneettiissoo//iissoo__eerrrrnnoo..hh>>
##iinncclluuddee <<nneettiissoo//ttpp__ppaarraamm..hh>>
##iinncclluuddee <<nneettiissoo//ttpp__uusseerr..hh>>
_i_n_t
ssoocckkeett(_[_A_F___I_N_E_T_, _A_F___I_S_O_], _S_O_C_K___S_E_Q_P_A_C_K_E_T, _0);
DDEESSCCRRIIPPTTIIOONN
The TP protocol provides reliable, flow-controlled, two-way transmission
of data and record boundaries. It is a byte-stream protocol and is ac-
cessed 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.
Sockets utilizing the tp protocol are either ``active'' or ``passive''.
Active sockets initiate connections to passive sockets. By default TCP
sockets are created active; to create a passive socket the listen(2) sys-
tem call must be used after binding the socket with the bind(2) system
call. Only passive sockets may use the accept(2) call to accept incoming
connections. Only active sockets may use the connect(2) call to initiate
connections.
Passive sockets may ``underspecify'' their location to match incoming
connection requests from multiple networks. This technique, termed
``wildcard addressing'', 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.
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 "expe-
dited data" service. Class 0 is essentially a null transport protocol,
which is used when the underlying network service provides reliable, se-
quenced, 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.
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 sendmsg(2) and
recmsgv(2), and further discussion below for the formats of the data in
the ancillary data buffer. If the EOTSDU is not needed, the normal
read(2), and write(2) system calls may be used.
Through the getsockopt and setsockopt system calls, TP supports several
options to control such things as negotiable options in the protocol and
protocol strategies. The options are defined in <_n_e_t_i_s_o_/_t_p___u_s_e_r_._h>, and
are described below.
In the tables below, the options marked with a pound sign `#' may be used
with setsockopt after a connection is established. Others must be used
before the connection is established, in other words, before calling con-
nect or accept. All options may be used with getsockopt before or after
a connection is established.
TPOPT_CONN_DATA (char *) [none]
Data to send on connect. The passive user may issue a
getsockopt call to retrieve a connection request's us-
er data, after having done the accept system call
without implying confirmation of the connection.
The data may also be retrieved by issuing a recvmsg
request for ancillary data only, without implying con-
firmation of the connection. The returned _c_m_s_g_h_d_r
will contain SOL_TRANSPORT for the _c_s_m_g___l_e_v_e_l and
TPOPT_CONN_DATA for _c_m_s_g___t_y_p_e_.
TPOPT_DISC_DATA # (char *) [none]
Data to send on 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 close. This may be sent by a set-
sockopt system call, or by issuing a sendmsg request
specifying ancillary data only. The user-provided
_c_m_s_g_h_d_r must contain SOL_TRANSPORT for _c_s_m_g___l_e_v_e_l and
TPOPT_DISC_DATA for _c_m_s_g___t_y_p_e. Sending of disconnect
data will in of itself tear down (or reject) the con-
nection.
TPOPT_CFRM_DATA # (char *) [none]
Data to send when confirming a connection. This may
aslo be sent by a setsockopt system call, or by issu-
ing a sendmsg request, as above. Sending of connect
confirm data will cause the connection to be confirmed
rather than rejected.
TPOPT_PERF_MEAS # Boolean.
When true, performance measurements will be kept for
this connection. When set before a connection is es-
tablished, the active side will use a locally defined
parameter on the connect request packet; if the peer
is another ARGO implementation, this will cause per-
formance measurement to be turned on on the passive
side as well. See tpperf(8).
TPOPT_PSTATISTICS No associated value on input. On output, _s_t_r_u_c_t
_t_p___p_m_e_a_s.
This command is used to read the performance statis-
tics accumulated during a connection's lifetime. It
can only be used with getsockopt. The structure it
returns is described in <_n_e_t_i_s_o_/_t_p___s_t_a_t_._h>. See
tpperf(8).
TPOPT_FLAGS unsigned integer. [0x0]
This command can only be used with getsockopt. See
the description of the flags below.
TPOPT_PARAMS _s_t_r_u_c_t _t_p___c_o_n_n___p_a_r_a_m
Used to get or set a group parameters for a connec-
tion. The _s_t_r_u_c_t _t_p___c_o_n_n___p_a_r_a_m is the argument used
with the getsockopt or setsockopt system call. It is
described in <_n_e_t_i_s_o_/_t_p___u_s_e_r_._h>.
The fields of the _t_p___c_o_n_n___p_a_r_a_m structure are de-
scribed below.
_V_a_l_u_e_s _f_o_r _T_P_O_P_T___P_A_R_A_M_S_:
_p___N_r_e_t_r_a_n_s nonzero short integer [1]
Number of times a TPDU will be retransmitted before the
local TP entity closes a connection.
_p___d_r___t_i_c_k_s nonzero short integer [various]
Number of clock ticks between retransmissions of discon-
nect request TPDUs.
_p___d_t___t_i_c_k_s nonzero short integer [various]
Number of clock ticks between retransmissions of data
TPDUs. This parameter applies only to class 4.
_p___c_r___t_i_c_k_s nonzero short integer [various]
Number of clock ticks between retransmissions of connec-
tion request TPDUs.
_p___c_c___t_i_c_k_s nonzero short integer [various]
Number of clock ticks between retransmissions of connec-
tion confirm TPDUs. This parameter applies only to
class 4.
_p___x___t_i_c_k_s nonzero short integer [various]
Number of clock ticks between retransmissions of expe-
dited data TPDUs. This parameter applies only to class
4.
_p___s_e_n_d_a_c_k___t_i_c_k_s nonzero short integer [various]
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.
_p___r_e_f___t_i_c_k_s nonzero short integer [various]
Number of clock ticks for which a reference will be con-
sidered 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.
_p___i_n_a_c_t___t_i_c_k_s nonzero short integer [various]
Number of clock ticks without an incoming packet from
the peer after which TP close the connection. This pa-
rameter applies only to class 4.
_p___k_e_e_p_a_l_i_v_e___t_i_c_k_s
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 con-
nection). This parameter applies only to class 4.
_p___w_i_n_s_i_z_e short integer between 128 and 16384. [4096 bytes]
The buffer space limits in bytes for incoming and outgo-
ing 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 maxi-
mum TPDU size, and the rate at which the user program
receives data. This parameter applies only to class 4.
_p___t_p_d_u_s_i_z_e unsigned char between 0x7 and 0xd. [0xc for class 4]
[0xb for class 0]
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.
_p___a_c_k___s_t_r_a_t TPACK_EACH or TPACK_WINDOW. [TPACK_WINDOW]
This parameter applies only to class 4. Two acknowledg-
ment strategies are supported:
TPACK_EACH means that each data TPDU is acknowledged
with an AK TPDU.
TPACK_WINDOW means that upon receipt of the packet that
represents the high edge of the last window advertised,
and AK TPDU is generated.
_p___r_x___s_t_r_a_t 4 bit mask [TPRX_USE_CW | TPRX_FASTSTART] over connec-
tionless network protocols] [TPRX_USE_CW over connec-
tion-oriented network protocols]
This parameter applies only to class 4. The bit mask
may include the following values:
TPRX_EACH: When a retransmission timer expires, retrans-
mit each packet in the send window rather than just the
first unacknowledged packet.
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 re-
transmission occurs.
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 sud-
denly overloading the network with a burst of packets.
This strategy is also due to Van Jacobson.
_p___c_l_a_s_s 5 bit mask [TP_CLASS_4 | TP_CLASS_0]
Bit mask including one or both of the values TP_CLASS_4
and TP_CLASS_0. The higher class indicated is the pre-
ferred class. If only one class is indicated, negotia-
tion will not occur during connection establishment.
_p___x_t_d___f_o_r_m_a_t Boolean. [false]
Boolean indicating that extended format shall be negoti-
ated. This parameter applies only to class 4.
_p___x_p_d___s_e_r_v_i_c_e Boolean. [true]
Boolean indicating that the expedited data transport
service will be negotiated. This parameter applies only
to class 4.
_p___u_s_e___c_h_e_c_k_s_u_m Boolean. [true]
Boolean indicating the the use of checksums will be ne-
gotiated. This parameter applies only to class 4.
_p___u_s_e___n_x_p_d Reserved for future use.
_p___u_s_e___r_c_c Reserved for future use.
_p___u_s_e___e_f_c Reserved for future use.
_p___n_o___d_i_s_c___i_n_d_i_c_a_t_i_o_n_s
Boolean. [false]
Boolean indicating that the local TP entity shall not
issue indications (signals) when a TP connection is dis-
connected.
_p___d_o_n_t___c_h_a_n_g_e___p_a_r_a_m_s
Boolean. [false]
If _t_r_u_e 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 per-
tains.
_p___n_e_t_s_e_r_v_i_c_e One of { ISO_CLNS, ISO_CONS, ISO_COSNS, IN_CLNS }.
[ISO_CLNS]
Indicates which network service is to be used.
ISO_CLNS indicates the connectionless network service
provided by CLNP (ISO 8473).
ISO_CONS indicates the connection-oriented network ser-
vice provided by X.25 (ISO 8208) and ISO 8878.
ISO_COSNS indicates the connectionless network service
running over a connection-oriented subnetwork service:
CLNP (ISO 8473) over X.25 (ISO 8208).
IN_CLNS indicates the DARPA Internet connectionless net-
work service provided by IP (RFC 791).
_p___d_u_m_m_y Reserved for future use.
The TPOPT_FLAGS option is used for obtaining various boolean-valued op-
tions. 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.
_V_a_l_u_e_s _f_o_r _T_P_O_P_T___F_L_A_G_S_:
BBiittss DDeessccrriippttiioonn [[DDeeffaauulltt]]
0 TPFLAG_NLQOS_PDN: set when the quality of the network service is
similar to that of a public data network.
1 TPFLAG_PEER_ON_SAMENET: set when the peer TP entity is considered
to be on the same network as the local TP entity.
2 Not used.
3 TPFLAG_XPD_PRES: set when expedited data are present [0]
4..7 Reserved.
EERRRROORR VVAALLUUEESS
The TP entity returns _e_r_r_n_o error values as defined in <_s_y_s_/_e_r_r_n_o_._h> and
<_n_e_t_i_s_o_/_i_s_o___e_r_r_n_o_._h>. User programs may print messages associated with
these value by using an expanded version of perror found in the ISO li-
brary, _l_i_b_i_s_o_d_i_r_._a.
If the TP entity encounters asynchronous events that will cause a trans-
port 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 _e_r_r_n_o 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 accept(2) that timed out, the read may result in ENOTSOCK, because the
accept 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 ap-
proaches:
Block SIGURG
If the program is servicing only one connection, it can block or
ignore SIGURG during connection establishment. The advantage of
this is that the _e_r_r_n_o 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.
Handle 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 ser-
vice SIGURG. It can use the ggeettssoocckkoopptt(_._._._T_P_O_P_T___F_L_A_G_S_._._.) system
call to see if the signal was due to the arrival of expedited da-
ta or due to a disconnection. In the latter case, getsockopt
will return ENOTCONN.
SSEEEE AALLSSOO
tcp(4), netstat(1), iso(4), clnp(4), cltp(4), ifconfig(8).
BBUUGGSS
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 applica-
tion. 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 ex-
pedited data but have no room to receive more." The TP entity has the
choice of acknowledging receipt of the XPD TPDU:
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 con-
nection after retransmission, or
when the TP entity receives it
so the sending entity does not retransmit or close the connec-
tion. 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).
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.
4.4BSD June 9, 1993 6