.\" Copyright (c) 1990, 1991 The Regents of the University of California.
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" 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
.\" @(#)tp.4 6.4 (Berkeley) 3/28/91
.Fd #include <sys/socket.h>
.Fd #include <netiso/iso_errno.h>
.Fd #include <netiso/tp_param.h>
.Fd #include <netiso/tp_user.h>
.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0
protocol provides reliable, flow-controlled, two-way
transmission of data and record boundaries.
It is a byte-stream protocol and is accessed according to
protocol makes use of a standard
including a Network Service Access Point, and a Transport Service Entity
Subclass 4 may make use of the internet
Sockets utilizing the tp protocol are either
Active sockets initiate connections to passive
sockets are created active; to create a
after binding the socket with the
passive sockets may use the
call to accept incoming connections. Only active sockets may
call to initiate connections.
incoming connection requests from multiple networks. This
.Dq wildcard addressing ,
server to provide service to clients on multiple networks.
To create a socket which listens on all networks, the
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.
Transport Protocol implemented for
at the University of Wisconsin - Madison,
and modified for inclusion in the Berkeley Software Distribution,
Class 4 of the protocol provides reliable, sequenced,
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
Class 4 may be used in the Internet domain as well as in the
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
indication, and for the receipt and transmission of user
connect, confirm, and disconnect data.
below for the formats of the data in the ancillary data buffer.
is not needed, the normal
system calls may be used.
to control such things as negotiable options
in the protocol and protocol strategies.
The options are defined in
.Aq Pa netiso/tp_user.h ,
the options marked with a pound sign
after a connection is established.
Others must be used before the connection
is established, in other words,
after a connection is established.
.Bl -tag -width TPOPT_PSTATISTICS
The passive user may issue a
call to retrieve a connection request's user data,
system call without implying confirmation of the connection.
The data may also be retrieved by issuing a
request for ancillary data only,
without implying confirmation of the connection.
.It Dv TPOPT_DISC_DATA \&#
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
system call, or by issuing a
request specifying ancillary data only.
Sending of disconnect data will in of itself tear down (or reject)
.It Dv TPOPT_CFRM_DATA \&#
Data to send when confirming a connection.
This may aslo be sent by a
system call, or by issuing a
Sending of connect confirm data will cause the connection
to be confirmed rather than rejected.
.It Dv TPOPT_PERF_MEAS \&#
performance measurements will be kept
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
implementation, this will cause performance measurement to be
on the passive side as well.
No associated value on input.
This command is used to read the performance statistics accumulated
during a connection's lifetime.
The structure it returns is described in
.Aq Pa netiso/tp_stat.h .
This command can only be used with
See the description of the flags below.
Used to get or set a group parameters for a connection.
is the argument used with the
.Aq Pa netiso/tp_user.h .
.Em Values for TPOPT_PARAMS:
.Bl -tag -width p_sendack_ticks
nonzero short integer [1]
will be retransmitted before the
local TP entity closes a connection.
nonzero short integer [various]
Number of clock ticks between retransmissions of disconnect request
nonzero short integer [various]
Number of clock ticks between retransmissions of data
This parameter applies only to class 4.
nonzero short integer [various]
Number of clock ticks between retransmissions of connection request
nonzero short integer [various]
Number of clock ticks between retransmissions of connection confirm
This parameter applies only to class 4.
nonzero short integer [various]
Number of clock ticks between retransmissions of expedited data
This parameter applies only to class 4.
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
This parameter applies only to class 4.
nonzero short integer [various]
Number of clock ticks for which a reference will
be considered frozen after the connection to which
This parameter applies to classes 4 and 0 in the
implementation, despite the fact that
the frozen reference function is required only for
nonzero short integer [various]
Number of clock ticks without an incoming packet from the peer after which
This parameter applies only to class 4.
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.
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 different limits for incoming and outgoing
The actual window size at any time
during the lifetime of a connection
is a function of the buffer size limit, the negotiated
rate at which the user program receives data.
This parameter applies only to class 4.
unsigned char between 0x7 and 0xd.
[0xc for class 4] [0xb for class 0]
Log 2 of the maximum TPDU size to be negotiated.
8473) gives an upper bound of
0xd for class 4 and 0xb for class 0.
implementation places upper bounds of
0xc on class 4 and 0xb on class 0.
This parameter applies only to class 4.
Two acknowledgment strategies are supported:
.Dv TPACK_EACH means that each data TPDU
means that upon receipt of the packet that represents
the high edge of the last window advertised, and AK TPDU is generated.
.Bq Dv TPRX_USE_CW No \&|\ Dv TPRX_FASTSTART
connectionless network protocols]
connection-oriented network protocols]
This parameter applies only to class 4.
The bit mask may include the following values:
When a retransmission timer expires, retransmit
each packet in the send window rather than
just the first unacknowledged packet.
Use a "congestion window" strategy borrowed
from Van Jacobson's congestion window strategy for TCP.
The congestion window size is set to one whenever
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.
.Bq Dv TP_CLASS_4 No \&|\ Dv TP_CLASS_0
Bit mask including one or both of the values
The higher class indicated is the preferred class.
If only one class is indicated, negotiation will not occur
during connection establishment.
Boolean indicating that extended format shall be negotiated.
This parameter applies only to class 4.
the expedited data transport service will be negotiated.
This parameter applies only to class 4.
Boolean indicating the the use of checksums will be negotiated.
This parameter applies only to class 4.
.It Ar p_no_disc_indications
Boolean indicating that the local
indications (signals) when a
connection is disconnected.
.It Ar p_dont_change_params
any of the other values given in this structure.
If the values cannot be used, the
entity will drop, disconnect,
or refuse to establish the connection to which this structure pertains.
Indicates which network service is to be used.
indicates the connectionless network service provided
indicates the connection-oriented network service provided
connectionless network service running over a
connection-oriented subnetwork service: CLNP
DARPA Internet connectionless network service provided by IP (RFC 791).
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.
.Em Values for TPOPT_FLAGS:
.Sy Description [Default]
set when the quality of the
similar to that of a public data network.
.Dv TPFLAG_PEER_ON_SAMENET :
is considered to be on the same network as the local
set when expedited data are present
error values as defined in
.Aq Pa netiso/iso_errno.h .
User programs may print messages associated with these value by
using an expanded version of
entity encounters asynchronous events
that will cause a transport connection to be closed,
timing out while retransmitting a connect request TPDU,
disconnection has occurred.
If the signal is issued during a
a system call, the system call may be interrupted,
value upon return from the system call is
is being handled by reading
from the socket, and it was a
timed out, the read may result in
call had not yet returned a
legitimate socket descriptor when the signal was handled.
(or a some other errno value appropriate to the
type of error) is returned if
for the duration of the system call.
A user program should take one of the following approaches:
If the program is servicing
only one connection, it can block or ignore
The advantage of this is that the
returned is somewhat meaningful.
The disadvantage of this is that
if ignored, disconnection and expedited data indications could be
For some programs this is not a problem.
If the program is servicing more than one connection at a time
or expedited data may arrive or both, the program may elect to
.Fn getsockopt ...TPOPT_FLAGS...
call to see if the signal
was due to the arrival of expedited data or due to a disconnection.
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
depends on the application.
The problem is not of major significance since most applications
do not use transport expedited data.
the expedited data acknowledgment TPDU
has no field for conveying
credit, thus it is not possible for a
entity to inform its peer
that "I received your expedited data but have no room to receive more."
entity has the choice of acknowledging receipt of the
.It "when the user receives the" XPD TSDU
which may be a fairly long time,
which may cause the sending
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
the expedited data will not be acknowledged (until the
receiving user receives the first XPD TSDU).
implementation acknowledges XPD TPDUs
in the hope that most users will not use expedited data requently
enough for this to be a problem.