TP(4)                   NetBSD Kernel Interfaces Manual                  TP(4)

     tp -- ISO Transport Protocol

     #include <sys/socket.h>
     #include <netiso/iso_errno.h>
     #include <netiso/tp_param.h>
     #include <netiso/tp_user.h>

     socket([AF_INET, AF_ISO], SOCK_SEQPACKET, 0);

     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.  Subclass 4 may
     make use of the Internet address format.

     Sockets using 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

     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 alternative stop-and-wait data path called the
     "expedited data" service.  Class 0 is essentially a null transport proto-
     col, 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 of the end-of-transport-ser-
     vice-data-unit (EOTSDU) indication, and for the receipt and transmission
     of user connect, confirm, and disconnect data.  See sendmsg(2) and
     recvmsg(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(2) and setsockopt(2) system calls, TP supports
     several options to control such things as negotiable options in the pro-
     tocol and protocol strategies.  The options are defined in
     <netiso/tp_user.h>, and are described below.

     In the tables below, the options marked with a pound sign `#' may be used
     with setsockopt(2) after a connection is established.  Others must be
     used before the connection is established, in other words, before calling
     connect(2) or accept(2).  All options may be used with getsockopt(2)
     before or after a connection is established.

     TPOPT_CONN_DATA    (char *) [none]
                        Data to send on connect(2).  The passive user may
                        issue a getsockopt(2) call to retrieve a connection
                        request's user data, after having done the accept(2)
                        system call without implying confirmation of the con-

                        The data may also be retrieved by issuing a recvmsg(2)
                        request for ancillary data only, without implying con-
                        firmation of the connection.  The returned cmsghdr
                        will contain SOL_TRANSPORT for the cmsg_level and
                        TPOPT_CONN_DATA for cmsg_type.

     TPOPT_DISC_DATA #  (char *) [none]
                        Data to send on close(2).  Disconnect data may be sent
                        by the side initiating the close but not by the pas-
                        sive side ("passive" with respect to the closing of
                        the connection), so there is no need to read discon-
                        nect data after calling close(2).  This may be sent by
                        a setsockopt(2) system call, or by issuing a
                        sendmsg(2) request specifying ancillary data only.
                        The user-provided cmsghdr must contain SOL_TRANSPORT
                        for cmsg_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 connection.  This may
                        also be sent by a setsockopt(2) system call, or by
                        issuing a sendmsg(2) 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
                        established, the active side will use a locally
                        defined parameter on the connect request packet; if
                        the peer is another ARGO implementation, this will
                        cause performance measurement to be turned on on the
                        passive side as well.

     TPOPT_PSTATISTICS  No associated value on input.  On output, struct

                        This command is used to read the performance statis-
                        tics accumulated during a connection's lifetime.  It
                        can only be used with getsockopt(2).  The structure it
                        returns is described in <netiso/tp_stat.h>.

     TPOPT_FLAGS        unsigned integer. [0x0]
                        This command can only be used with getsockopt(2).  See
                        the description of the flags below.

     TPOPT_PARAMS       struct tp_conn_param
                        Used to get or set a group parameters for a connec-
                        tion.  The struct tp_conn_param is the argument used
                        with the getsockopt(2) or setsockopt(2) system call.
                        It is described in <netiso/tp_user.h>.

                        The fields of the tp_conn_param structure are
                        described below.

     Values for TPOPT_PARAMS:

     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 discon-
                      nect 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 retransmissions of connec-
                      tion request TPDUs.

     p_cc_ticks       nonzero short integer [various]
                      Number of clock ticks between retransmissions of connec-
                      tion confirm TPDUs.  This parameter applies only to
                      class 4.

     p_x_ticks        nonzero short integer [various]
                      Number of clock ticks between retransmissions of expe-
                      dited data TPDUs.  This parameter applies only to class

     p_sendack_ticks  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
                      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 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_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.

                      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_winsize        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_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

     p_ack_strat      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,
                      an AK TPDU is generated.

     p_rx_strat       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
                      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 peer window's real 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_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 indicated is the pre-
                      ferred class.  If only one class is indicated, negotia-
                      tion will not occur during connection establishment.

     p_xtd_format     Boolean.  [false]
                      Boolean indicating that extended format is 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 use of checksums will be negoti-
                      ated.  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.

                      Boolean.  [false]

                      Boolean indicating that the local TP entity will not
                      issue indications (signals) when a TP connection is dis-

                      Boolean.  [false]
                      If true 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-

     p_netservice     One of { ISO_CLNS, ISO_CONS, ISO_COSNS, IN_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_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 significant bit.

     Values for TPOPT_FLAGS:

     Bits   Description [Default]

     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.

     The TP entity returns errno error values as defined in <sys/errno.h> and

     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 system call, the system call may be interrupted, in
     which case the errno value upon return from the system call is EINTR.  If
     the signal SIGURG is being handled by reading from the socket, and it was
     an accept(2) that timed out, the read may result in ENOTSOCK, because the
     accept(2) call had not yet returned a legitimate socket descriptor when
     the signal was handled.  ETIMEDOUT (or a some other errno value appropri-
     ate to the type of error) is returned if SIGURG is blocked for the dura-
     tion of the system call.  A user program should take one of the following

     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 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.

     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 getsockopt(...TPOPT_FLAGS...)  sys-
             tem call to see if the signal was due to the arrival of expedited
             data or due to a disconnection.  In the latter case,
             getsockopt(2) will return ENOTCONN.

     netstat(1), clnp(4), cltp(4), iso(4), tcp(4), ifconfig(8)

     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 sent within time epsilon, where epsilon depends on the
     application.  The problem is not of major significance since most appli-
     cations 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 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 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 frequently enough for this to
     be a problem.

NetBSD 6.1                      April 19, 1994                      NetBSD 6.1

You can also request any man page by name and (optionally) by section:


Use the DEFAULT collection to view manual pages for third-party software.

©1994 Man-cgi 1.15, Panagiotis Christias
©1996-2018 Modified for NetBSD by Kimmo Suominen