4.3BSD-Reno/share/man/cat4/tp.0
TP(4) 1990 TP(4)
NNAAMMEE
NNAAMMEE
TP - ISO Transport Protocol
SSYYNNOOPPSSIISS
##iinncclluuddee <<ssyyss//ssoocckkeett..hh>>
##iinncclluuddee <<nneettiissoo//iissoo__eerrrrnnoo..hh>>
##iinncclluuddee <<nneettiissoo//ttpp__ppaarraamm..hh>>
##iinncclluuddee <<nneettiissoo//ttpp__uusseerr..hh>>
ss == ssoocckkeett(( [[ AAFF__IINNEETT,, AAFF__IISSOO ]] ,, SSOOCCKK__SSEEQQPPAACCKKEETT,, 00));;
DDEESSCCRRIIPPTTIIOONN
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. Sub-
class 4 may make use of the internet Internet address for-
mat.
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 _l_i_s_t_e_n(2) system call must be
used after binding the socket with the _b_i_n_d(2) system call.
Only passive sockets may use the _a_c_c_e_p_t(2) call to accept
incoming connections. Only active sockets may use the _c_o_n_-
_n_e_c_t(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 net-
work 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 inclu-
sion 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 pro-
vides reliable, sequenced, flow-controlled, two-way
transmission of data packets with an alternate stop-and-wait
Printed 7/27/90 May 1
TP(4) 1990 TP(4)
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.
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 _s_e_n_d_m_s_g(_2) and _r_e_c_m_s_g_v(_2), and
further discussion below for the formats of the data in the
ancillary data buffer. If the EOTSDU is not needed, the
normal _r_e_a_d(2), and _w_r_i_t_e(2) system calls may be used.
Through the _g_e_t_s_o_c_k_o_p_t and _s_e_t_s_o_c_k_o_p_t system calls, TP sup-
ports several options to control such things as negotiable
options in the protocol and protocol strategies. The
options are defined in <<nneettiissoo//ttpp__uusseerr..hh>>, and are described
below.
In the tables below, the options marked with a pound sign (
## ) may be used with _s_e_t_s_o_c_k_o_p_t() after a connection is
established. Others must be used before the connection is
established, in other words, before calling _c_o_n_n_e_c_t() or
_a_c_c_e_p_t(). All options may be used with _g_e_t_s_o_c_k_o_p_t() before
or after a connection is established.
NNaammee VVaalluuee [[ddeeffaauulltt]]
DDeessccrriippttiioonn
TPOPT_CONN_DATA (char *) [none]
Data to send on _c_o_n_n_e_c_t(). The
passive user may issue a _g_e_t_-
_s_o_c_k_o_p_t() call to retrieve a con-
nection request's user data, after
having done the _a_c_c_e_p_t() system
call without implying confirmation
of the connection.
The data may also be retrieved by
issuing a _r_e_c_v_m_s_g() request for
ancillary data only, without imply-
ing confirmation of the connection.
The returned cmsghdr will contain
Printed 7/27/90 May 2
TP(4) 1990 TP(4)
SOL_TRANSPORT for the csmg_level
and TPOPT_CONN_DATA for cmsg_type.
TPOPT_DISC_DATA ## (char *) [none]
Data to send on _c_l_o_s_e(). Discon-
nect data may be sent by the side
initiating the close but not by the
passive side ("passive" with
respect to the closing of the con-
nection), so there is no need to
read disconnect data after calling
_c_l_o_s_e(). This may be sent by a
_s_e_t_s_o_c_k_o_p_t() system call, or by
issuing a _s_e_n_d_m_s_g() request speci-
fying 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.
TPOPT_CFRM_DATA ## (char *) [none]
Data to send when confirming a con-
nection. This may aslo be sent by
a _s_e_t_s_o_c_k_o_p_t() system call, or by
issuing a _s_e_n_d_m_s_g() request, as
above. Sending of connect confirm
data will cause the connection to
be confirmed rather than rejected.
TPOPT_PERF_MEAS ## Boolean.
When ttrruuee, 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 implementa-
tion, this will cause performance
measurement to be turned on on the
passive side as well. See
_t_p_p_e_r_f(_8).
TPOPT_PSTATISTICS No associated value on input. On
output, struct tp_pmeas.
This command is used to read the
performance statistics accumulated
Printed 7/27/90 May 3
TP(4) 1990 TP(4)
during a connection's lifetime. It
can only be used with _g_e_t_s_o_c_k_o_p_t().
The structure it returns is
described in <<nneettiissoo//ttpp__ssttaatt..hh>>.
See _t_p_p_e_r_f(_8).
TPOPT_FLAGS unsigned integer. [ 0x0 ]
This command can only be used with
_g_e_t_s_o_c_k_o_p_t(). See the description
of the flags below.
TPOPT_PARAMS struct tp_conn_param.
Used to get or set a group parame-
ters for a connection. The struct
tp_conn_param is the argument used
with the _g_e_t_s_o_c_k_o_p_t() or _s_e_t_-
_s_o_c_k_o_p_t() system call. It is
described in <<nneettiissoo//ttpp__uusseerr..hh>>.
The fields of the _t_p__c_o_n_n__p_a_r_a_m structure are described
below.
_V_a_l_u_e_s _f_o_r _T_P_O_P_T__P_A_R_A_M_S:
FFiieelldd VVaalluuee [[ddeeffaauulltt]]
DDeessccrriippttiioonn
p_Nretrans nonzero short integer [ 1 ]
Number of times a TPDU will be
retransmitted before the local TP
entity closes a connection.
p_dr_ticks nonzero short integer [ various ]
Number of clock ticks between
retransmissions of disconnect
request TPDUs.
p_dt_ticks nonzero short integer [ various ]
Number of clock ticks between
retransmissions of data TPDUs.
This parameter applies only to
class 4.
p_cr_ticks nonzero short integer [ various ]
Number of clock ticks between
Printed 7/27/90 May 4
TP(4) 1990 TP(4)
retransmissions of connection
request TPDUs.
p_cc_ticks nonzero short integer [ various ]
Number of clock ticks between
retransmissions of connection con-
firm TPDUs. This parameter applies
only to class 4.
p_x_ticks nonzero short integer [ various ]
Number of clock ticks between
retransmissions of expedited data
TPDUs. This parameter applies only
to class 4.
p_sendack_ticks nonzero short integer [ various ]
Number of clock ticks that the
local TP entity will wait before
sending an acknowledgment for nor-
mal data (not applicable if the
acknowlegement strategy is
TPACK_EACH). This parameter
applies only to class 4.
p_ref_ticks nonzero short integer [ various ]
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.
p_inact_ticks nonzero short integer [ various ]
Number of clock ticks without an
incoming packet from the peer after
which TP close the connection.
This parameter applies only to
class 4.
p_keepalive_ticks nonzero short integer [ various ]
nonzero short integer [ various ]
Number of clock ticks between ack-
nowledgments that are sent to keep
Printed 7/27/90 May 5
TP(4) 1990 TP(4)
an inactive connection open (to
prevent the peer's inactivity con-
trol function from closing the con-
nection). This parameter applies
only to class 4.
p_winsize short integer between 128 and
16384. [4096 bytes]
The buffer space limits in bytes
for incoming and outgoing data.
There is no way to specify dif-
ferent limits for incoming and out-
going paths. The actual window
size at any time during the life-
time of a connection is a function
of the buffer size limit, the nego-
tiated maximum TPDU size, and the
rate at which the user program
receives data. This parameter
applies only to class 4.
p_tpdusize 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_ack_strat TPACK_EACH or TPACK_WINDOW. [
TPACK_WINDOW ]
This parameter applies only to
class 4. Two acknowledgment stra-
tegies 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_rx_strat 4 bit mask [ TPRX_USE_CW |
Printed 7/27/90 May 6
TP(4) 1990 TP(4)
TPRX_FASTSTART over connectionless
network protocols ] [ TPRX_USE_CW
over connection-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, retransmit each
packet in the send window rather
than just the first unacknowledged
packet.
TPRX_USE_CW: Use a "congestion win-
dow" strategy borrowed from Van
Jacobson's congestion window stra-
tegy for TCP. The congestion win-
dow size is set to one whenever a
retransmission 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 connec-
tions on a congested network by
preventing a transport connection
from suddenly overloading the net-
work with a burst of packets. This
strategy is also due to Van Jacob-
son.
p_class 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 indi-
cated is the preferred class. If
only one class is indicated, nego-
tiation will not occur during con-
nection establishment.
p_xtd_format Boolean. [ false ]
Boolean indicating that extended
Printed 7/27/90 May 7
TP(4) 1990 TP(4)
format shall be negotiated. This
parameter applies only to class 4.
p_xpd_service Boolean. [ true ]
Boolean indicating that the
expedited data transport service
will be negotiated. This parameter
applies only to class 4.
p_use_checksum Boolean. [ true ]
Boolean indicating the the use of
checksums will be negotiated. This
parameter applies only to class 4.
p_use_nxpd Reserved for future use.
p_use_rcc Reserved for future use.
p_use_efc Reserved for future use.
p_no_disc_indications Boolean. [ false ]
Boolean indicating that the local
TP entity shall not issue indica-
tions (signals) when a TP connec-
tion is disconnected.
p_dont_change_params Boolean. [ false ]
If ttrruuee 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.
p_netservice One of { ISO_CLNS, ISO_CONS,
ISO_COSNS, IN_CLNS }. [ ISO_CLNS ]
Indicates which network service is
to be used.
ISO_CLNS indicates the connection-
less network service provided by
CLNP (ISO 8473).
ISO_CONS indicates the connection-
oriented network service provided
by X.25 (ISO 8208) and ISO 8878.
Printed 7/27/90 May 8
TP(4) 1990 TP(4)
ISO_COSNS indicates the connection-
less network service running over a
connection-oriented subnetwork ser-
vice : CLNP (ISO 8473) over X.25
(ISO 8208).
IN_CLNS indicates the DARPA Inter-
net connectionless network service
provided by IP (RFC 791).
p_dummy Reserved for future use.
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 signi-
ficant 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
<<ssyyss//eerrrrnnoo..hh>> and <<nneettiissoo//iissoo__eerrrrnnoo..hh>>. User programs may
print messages associated with these value by using an
expanded version of _p_e_r_r_o_r() found in the ISO library,
_l_i_b_i_s_o_d_i_r._a.
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 receiv-
ing a DR TPDU, the TP entity issues a SIGURG signal, indi-
cating that disconnection has occurred. If the signal is
issued during a a system call, the system call may be inter-
rupted, in which case the _e_r_r_n_o value upon return from the
Printed 7/27/90 May 9
TP(4) 1990 TP(4)
system call is EINTR. If the signal SIGURG is being handled
by reading from the socket, and it was a _a_c_c_e_p_t() that timed
out, the read may result in ENOTSOCK, because the _a_c_c_e_p_t()
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:
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 indi-
cations 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 pro-
gram may elect to service SIGURG. It can use the
_g_e_t_s_o_c_k_o_p_t(..._T_P_O_P_T__F_L_A_G_S...) system call to see if the
signal was due to the arrival of expedited data or due
to a disconnection. In the latter case, _g_e_t_s_o_c_k_o_p_t()
will return ENOTCONN.
BBUUGGSS
The protocol definition of expedited data is slightly prob-
lematic, in a way that renders expedited data almost use-
less, if two or more packets of expedited data are send
within time C-, where C- 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 con-
veying 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
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
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).
Printed 7/27/90 May 10
TP(4) 1990 TP(4)
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.
SSEEEE AALLSSOO
tcp(4), netstat(1), iso(4), clnp(4), cltp(4), ifconfig(8).
Printed 7/27/90 May 11