TP man page on 4.4BSD

Man page or keyword search:  
man Server   1065 pages
apropos Keyword Search (all sections)
Output format
4.4BSD logo
[printable version]

TP(4)			 BSD 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 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

     Passive sockets may “underspecify” their location to match incoming con‐
     nection 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,
     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 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 ⟨netiso/tp_user.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
     connect 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
			user 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 cmsghdr
			will contain SOL_TRANSPORT for the csmg_level and
			TPOPT_CONN_DATA for cmsg_type.

     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
			setsockopt system call, or by issuing a sendmsg
			request specifying ancillary data only.	 The user-pro‐
			vided 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 connection.  This may
			also 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
			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.  See tpperf(8).

     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.  The structure it
			returns is described in ⟨netiso/tp_stat.h⟩.  See

     TPOPT_FLAGS	unsigned integer. [0x0]
			This command can only be used with getsockopt.	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 or setsockopt 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 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.

		      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
     ⟨netiso/iso_errno.h⟩.  User programs may print messages associated with
     these value by using an expanded version of perror found in the ISO
     library, libisodir.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 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 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

     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
	     will return ENOTCONN.

     tcp(4), netstat(1), iso(4), clnp(4), cltp(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 send within time ε, where ε 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
     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.

BSD				April 19, 1994				   BSD

List of man pages available for 4.4BSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net