Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

NetBSD 6.1.5 - man page for tp (netbsd section 4)

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 Net-
     work 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 pas-
     sive socket the listen(2) system 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 connec-
     tions.  Only active sockets may use the connect(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 asso-
     ciated 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 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

     Two system calls were modified from the previous release of the Berkeley Software Distribu-
     tion to permit the support of the end-of-transport-service-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 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(2)
     after a connection is established.  Others must be used before the connection is estab-
     lished, 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 connection.

			The data may also be retrieved by issuing a recvmsg(2) request for ancil-
			lary data only, without implying confirmation 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 initi-
			ating 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(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 tp_pmeas.

			This command is used to read the performance statistics accumulated dur-
			ing 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 connection.  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 disconnect request TPDUs.

     p_dt_ticks       nonzero short integer [various]
		      Number of clock ticks between retransmissions of data TPDUs.  This parame-
		      ter applies only to class 4.

     p_cr_ticks       nonzero short integer [various]
		      Number of clock ticks between retransmissions of connection request TPDUs.

     p_cc_ticks       nonzero short integer [various]
		      Number of clock ticks between retransmissions of connection confirm 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 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 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.

		      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.

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

     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 acknowledgment strategies are

		      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 connectionless network pro-
		      tocols] [TPRX_USE_CW over connection-oriented network protocols]
		      This parameter applies only to class 4.  The bit mask may include the fol-
		      lowing 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 window" strategy borrowed from Van Jacob-
		      son'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 suddenly 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 preferred class.  If only one class is
		      indicated, negotiation 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 nego-
		      tiated.  This parameter applies only to class 4.

     p_use_checksum   Boolean.	[true]
		      Boolean indicating 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 disconnected.

		      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

     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 connectionless network service provided by CLNP (ISO

		      ISO_CONS indicates the connection-oriented network service provided by X.25
		      (ISO 8208) and ISO 8878.

		      ISO_COSNS indicates the connectionless network service running over a con-
		      nection-oriented subnetwork service: CLNP (ISO 8473) over X.25 (ISO 8208).

		      IN_CLNS indicates the DARPA Internet connectionless network service pro-
		      vided 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 transport 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 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 dur-
	     ing connection establishment.  The advantage of this is that the errno value
	     returned is somewhat meaningful.  The disadvantage of this is that if ignored, dis-
	     connection 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 service SIGURG.  It can use the
	     getsockopt(...TPOPT_FLAGS...)  system 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 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 possi-
     ble 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).

     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

All times are GMT -4. The time now is 08:45 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?