Table of Contents
Transport Protocol
The 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 abstraction. The protocol makes use of
a standard 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
or Active sockets initiate connections to passive sockets. By default
sockets are created active; to create a passive socket the system call
must be used after binding the socket with the system call. Only passive
sockets may use the call to accept incoming connections. Only active
sockets may use the call to initiate connections. Passive sockets may
their location to match incoming connection requests from multiple networks.
This technique, termed allows a single server to provide service to clients
on multiple networks. To create a socket which listens on all networks,
the 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 Transport Protocol implemented
for at the University of Wisconsin - Madison, and modified for inclusion
in the Berkeley Software Distribution, includes classes 0 and 4 of the
transport protocols as specified in the June 1986 version of 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 domain. Class 4 may be used in the Internet domain as well
as in the domain. 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
indication, and for the receipt and transmission of user connect, confirm,
and disconnect data. See and and further discussion below for the formats
of the data in the ancillary data buffer. If the is not needed, the normal
and system calls may be used. Through the and system calls, supports
several options to control such things as negotiable options in the protocol
and protocol strategies. The options are defined in and are described below.
In the tables below, the options marked with a pound sign may be used
with after a connection is established. Others must be used before the
connection is established, in other words, before calling or All options
may be used with before or after a connection is established. (char
*) [none]
Data to send on The passive user may issue a call to retrieve a connection
request’s user data, after having done the 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. The returned will contain for the and for (char *) [none]
Data to send on 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
This may be sent by a system call, or by issuing a request specifying
ancillary data only. The user-provided must contain for and for Sending
of disconnect data will in of itself tear down (or reject) the connection.
(char *) [none]
Data to send when confirming a connection. This may also be sent by a
system call, or by issuing a request, as above. Sending of connect confirm
data will cause the connection to be confirmed rather than rejected. Boolean.
When 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
implementation, this will cause performance measurement to be turned on
on the passive side as well. See No associated value on input. On output,
This command is used to read the performance statistics accumulated during
a connection’s lifetime. It can only be used with The structure it returns
is described in See unsigned integer. [0x0]
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. The is the argument
used with the or system call. It is described in The fields of the
structure are described below. nonzero short integer [1]
Number of times a TPDU will be retransmitted before the local TP entity
closes a connection. nonzero short integer [various]
Number of clock ticks between retransmissions of disconnect request TPDUs.
nonzero short integer [various]
Number of clock ticks between retransmissions of data TPDUs. This parameter
applies only to class 4. nonzero short integer [various]
Number of clock ticks between retransmissions of connection request TPDUs.
nonzero short integer [various]
Number of clock ticks between retransmissions of connection confirm TPDUs.
This parameter applies only to class 4. nonzero short integer [various]
Number of clock ticks between retransmissions of expedited data TPDUs. 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 acknowledgement
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 it applied is closed. This parameter applies to
classes 4 and 0 in the implementation, despite the fact that the frozen
reference function is required only for class 4. nonzero short integer
[various]
Number of clock ticks without an incoming packet from the peer after which
close the connection. 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 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. 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 standard 8473) gives
an upper bound of 0xd for class 4 and 0xb for class 0. The implementation
places upper bounds of 0xc on class 4 and 0xb on class 0. or
This parameter applies only to class 4. Two acknowledgment strategies are
supported: is acknowledged with an AK TPDU. means that upon receipt
of the packet that represents the high edge of the last window advertised,
an AK TPDU is generated. 4 bit mask over connectionless network protocols]
over 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 a retransmission
occurs. 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. 5 bit mask
Bit mask including one or both of the values and The higher class indicated
is the preferred class. If only one class is indicated, negotiation will
not occur during connection establishment. Boolean. [false]
Boolean indicating that extended format is negotiated. This parameter applies
only to class 4. Boolean. [true]
Boolean indicating that the expedited data transport service will be negotiated.
This parameter applies only to class 4. Boolean. [true]
Boolean indicating the the use of checksums will be negotiated. This parameter
applies only to class 4. Reserved for future use. Reserved for future use.
Reserved for future use. Boolean. [false] Boolean indicating that the
local entity will not issue indications (signals) when a connection is
disconnected. Boolean. [false]
If the entity will not override 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.
One of {
Indicates which network service is to be used. indicates the connectionless
network service provided by CLNP 8473). indicates the connection-oriented
network service provided by X.25 8208) and 8878. indicates the connectionless
network service running over a connection-oriented subnetwork service: CLNP
8473) over X.25 8208). indicates the DARPA Internet connectionless
network service provided by IP (RFC 791). Reserved for future use. The
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.
set when the quality of the network service is similar to that
of a public data network. set when the peer entity is considered to be
on the same network as the local entity. Not used. set when expedited
data are present [0] Reserved.
The entity returns error
values as defined in and User programs may print messages associated
with these value by using an expanded version of found in the library,
If the 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 entity issues a 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 value upon
return from the system call is If the signal is being handled by reading
from the socket, and it was an that timed out, the read may result in
because the 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 is blocked 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 during
connection establishment. The advantage of this is that the 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. 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
It can use the system call to see if the signal was due to the arrival
of expedited data or due to a disconnection. In the latter case, will
return
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, 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." The entity
has the choice of acknowledging receipt of the XPD TPDU: 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
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). The implementation acknowledges XPD TPDUs immediately, in the
hope that most users will not use expedited data frequently enough for
this to be a problem.
Table of Contents