diff options
author | Jason McIntyre <jmc@cvs.openbsd.org> | 2004-07-15 23:25:07 +0000 |
---|---|---|
committer | Jason McIntyre <jmc@cvs.openbsd.org> | 2004-07-15 23:25:07 +0000 |
commit | 256a382eaf7f8963beace5967407b17c0b55f9d3 (patch) | |
tree | 742c031dc48a17e0771426326bb6b57208d798e9 /share/man | |
parent | ef6c2c98d54b454383df18e29316fbbaf9b3bda6 (diff) |
remove after iso removal;
ok henning@
Diffstat (limited to 'share/man')
-rw-r--r-- | share/man/man4/clnp.4 | 150 | ||||
-rw-r--r-- | share/man/man4/cltp.4 | 124 | ||||
-rw-r--r-- | share/man/man4/esis.4 | 214 | ||||
-rw-r--r-- | share/man/man4/iso.4 | 184 | ||||
-rw-r--r-- | share/man/man4/tp.4 | 721 |
5 files changed, 0 insertions, 1393 deletions
diff --git a/share/man/man4/clnp.4 b/share/man/man4/clnp.4 deleted file mode 100644 index 0af667f0103..00000000000 --- a/share/man/man4/clnp.4 +++ /dev/null @@ -1,150 +0,0 @@ -.\" $OpenBSD: clnp.4,v 1.8 2003/06/02 23:30:12 millert Exp $ -.\" $NetBSD: clnp.4,v 1.4 1994/11/30 16:22:07 jtc Exp $ -.\" -.\" Copyright (c) 1990, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 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. 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 -.\" SUCH DAMAGE. -.\" -.\" @(#)clnp.4 8.2 (Berkeley) 4/2/94 -.\" -.Dd April 2, 1994 -.Dt CLNP 4 -.Os -.Sh NAME -.Nm clnp -.Nd Connectionless-Mode Network Protocol -.Sh SYNOPSIS -.Fd #include <sys/socket.h> -.Fd #include <netiso/iso.h> -.Fd #include <netiso/clnp.h> -.Ft int -.Fn socket AF_ISO SOCK_RAW 0 -.Sh DESCRIPTION -CLNP is the connectionless-mode network protocol used by the -connectionless-mode network service. -This protocol is specified in ISO 8473. -It may be accessed through a -.Dq raw socket -for debugging purposes only. -CLNP sockets are connectionless, and are normally used with the -.Xr sendto 2 -and -.Xr recvfrom 2 -calls, though the -.Xr connect 2 -call may also be used to fix the destination for future -packets (in which case the -.Xr read 2 -or -.Xr recv 2 -and -.Xr write 2 -or -.Xr send 2 -system calls may be used). -.Pp -Outgoing packets automatically have a CLNP header prepended to them. -Incoming packets received by the user contain the full CLNP header. -The following -.Xr setsockopt 2 -options apply to CLNP: -.Bl -tag -width CLNPOPT_FLAGS -.It Dv CLNPOPT_FLAGS -Sets the flags which are passed to clnp when sending a datagram. -Valid flags are: -.Pp -.Bl -tag -width "CLNP_NO_CKSUM" -offset indent -compact -.It Dv CLNP_NO_SEG -Do not allow segmentation. -.It Dv CLNP_NO_ER -Suppress ER pdus. -.It Dv CLNP_NO_CKSUM -Do not generate the CLNP checksum. -.El -.Pp -.It Dv CLNPOPT_OPTS -Sets CLNP options. -The options must be formatted exactly as specified by ISO 8473, section 7.5. -.Dq Options Part. -Once an option has been set, it will be sent on all packets until -a different option is set. -.El -.Sh CONGESTION EXPERIENCE BIT -Whenever a packet is transmitted, the globally unique quality of -service option is added to the packet. -The sequencing preferred bit and the low transit delay bit are set in -this option. -.Pp -If a packet is forwarded containing the globally unique quality of -service option, and the interface through which the packet will be -transmitted has a queue length greater than -.Em congest_threshold , -then the congestion experienced bit is set in the quality of service option. -.Pp -The threshold value stored in -.Em congest_threshold -may be tuned. -.Pp -When a packet is received with the -globally unique quality of service option present, and the -congestion experienced bit is set, then the transport congestion -control function is called. -.Sh DIAGNOSTICS -A socket operation may fail with one of the following errors returned: -.Bl -tag -width [EADDRNOTAVAIL] -.It Bq Er EISCONN -When trying to establish a connection on a socket which -already has one, or when trying to send a datagram with the destination -address specified and the socket is already connected; -.It Bq Er ENOTCONN -When trying to send a datagram, but -no destination address is specified, and the socket hasn't been -connected; -.It Bq Er ENOBUFS -When the system runs out of memory for -an internal data structure; -.It Bq Er EADDRNOTAVAIL -When an attempt is made to create a -socket with a network address for which no network interface -exists; -.It Bq Er EHOSTUNREACH -When trying to send a datagram, but no route to the destination -address exists. -.It Bq Er EINVAL -When specifying unsupported options. -.El -.Sh SEE ALSO -.Xr recv 2 , -.Xr send 2 , -.Xr iso 4 , -.Xr netintro 4 -.Sh BUGS -Packets are sent with the type code of 0x1d (technically an invalid -packet type) for lack of a better way to identify raw CLNP packets. -.Pp -No more than -.Dv MLEN -bytes of options can be specified. diff --git a/share/man/man4/cltp.4 b/share/man/man4/cltp.4 deleted file mode 100644 index d368d1b5c03..00000000000 --- a/share/man/man4/cltp.4 +++ /dev/null @@ -1,124 +0,0 @@ -.\" $OpenBSD: cltp.4,v 1.8 2003/06/02 23:30:12 millert Exp $ -.\" $NetBSD: cltp.4,v 1.3 1994/11/30 16:22:08 jtc Exp $ -.\" -.\" Copyright (c) 1990, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 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. 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 -.\" SUCH DAMAGE. -.\" -.\" @(#)cltp.4 8.1 (Berkeley) 6/9/93 -.\" -.Dd June 9, 1993 -.Dt CLTP 4 -.Os -.Sh NAME -.Nm cltp -.Nd ISO Connectionless Transport Protocol -.Sh SYNOPSIS -.Fd #include <sys/socket.h> -.Fd #include <netiso/iso.h> -.Ft int -.Fn socket AF_ISO SOCK_DGRAM 0 -.Sh DESCRIPTION -.Tn CLTP -is a simple, unreliable datagram protocol which is accessed -via the -.Dv SOCK_DGRAM -abstraction for the -.Tn ISO -protocol family. -.Tn CLTP -sockets are connectionless, and are -normally used with the -.Xr sendto 2 -and -.Xr recvfrom 2 -calls, though the -.Xr connect 2 -call may also be used to fix the destination for future -packets (in which case the -.Xr recv 2 -or -.Xr read 2 -and -.Xr send 2 -or -.Xr write 2 -system calls may be used). -.Pp -.Tn CLTP -address formats are identical to those used by TP. -In particular -.Tn CLTP -provides a service selector in addition -to the normal -.Tn ISO NSAP . -Note that the -.Tn CLTP -selector -space is separate from the TP selector space (i.e. a -.Tn CLTP -selector -may not be -.Dq connected -to a TP selector). -.Pp -Options at the -.Tn CLNP -network level may be used with -.Tn CLTP ; -see -.Xr clnp 4 . -.Sh DIAGNOSTICS -A socket operation may fail with one of the following errors returned: -.Bl -tag -width [EADDRNOTAVAIL] -.It Bq Er EISCONN -when trying to establish a connection on a socket which -already has one, or when trying to send a datagram with the destination -address specified and the socket is already connected; -.It Bq Er ENOTCONN -when trying to send a datagram, but -no destination address is specified, and the socket hasn't been -connected; -.It Bq Er ENOBUFS -when the system runs out of memory for -an internal data structure; -.It Bq Er EADDRINUSE -when an attempt -is made to create a socket with a selector which has already been -allocated; -.It Bq Er EADDRNOTAVAIL -when an attempt is made to create a -socket with a network address for which no network interface -exists. -.El -.Sh SEE ALSO -.Xr getsockopt 2 , -.Xr recv 2 , -.Xr send 2 , -.Xr socket 2 , -.Xr clnp 4 , -.Xr iso 4 , -.Xr netintro 4 diff --git a/share/man/man4/esis.4 b/share/man/man4/esis.4 deleted file mode 100644 index 10cf7f33a3c..00000000000 --- a/share/man/man4/esis.4 +++ /dev/null @@ -1,214 +0,0 @@ -.\" $OpenBSD: esis.4,v 1.10 2004/03/21 19:47:59 miod Exp $ -.\" $NetBSD: esis.4,v 1.3 1994/11/30 16:22:12 jtc Exp $ -.\" -.\" Copyright (c) 1990, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 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. 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 -.\" SUCH DAMAGE. -.\" -.\" @(#)esis.4 8.2 (Berkeley) 11/30/93 -.\" -.Dd November 30, 1993 -.Dt ESIS 4 -.Os -.Sh NAME -.Nm ES-IS -.Nd End System to Intermediate System Routing Protocol -.Sh SYNOPSIS -.Cd "pseudo-device ether" Op Ar count -.Sh DESCRIPTION -The -.Nm ES-IS -routing protocol is used to dynamically map between -.Tn ISO NSAP -addresses and -.Tn ISO SNPA -addresses; to permit End and Intermediate Systems -to learn of each other's existence; and to allow Intermediate Systems -to inform End Systems of (potentially) better routes to use when -forwarding -.Tn NPDU Ns s -to a particular destination. -.Pp -The mapping between -.Tn NSAP -addresses and -.Tn SNPA -addresses is accomplished by -transmitting hello -.Tn PDU Ns s -between the cooperating Systems. -These -.Tn PDU Ns s -are transmitted whenever the -.Em configuration -timer expires. -When a hello -.Tn PDU -is received, the -.Tn SNPA -address that it conveys is stored in the routing table for as long as the -.Em holding time -in the -.Tn PDU -suggests. -The default -.Em holding time -(120 seconds) placed in the hello -.Tn PDU , -the configuration timer value, -and the system type (End System or Intermediate System) may be changed by -issuing an -.Dv SIOCSSTYPE -.Xr ioctl 2 , -which is defined in -.Pa /sys/netiso/iso_snpac.h . -.Pp -The protocol behaves differently depending on whether the System is -configured as an End System or an Intermediate System. -.Sh END SYSTEM OPERATION -When an interface requests a mapping for an address not in the cache, -the -.Tn SNPA -of any known Intermediate System is returned. -If an Intermediate System is not known, then the -.Em all end systems -multicast address -is returned. -It is assumed that the intended recipient of the NPDU will immediately -transmit a hello -.Tn PDU -back to the originator of the -.Tn NPDU . -.Pp -If an -.Tn NPDU -is forwarded by the End System, a redirect -.Tn PDU -will not be -generated. -However, redirect -.Tn PDU Ns s -received will be processed. -This processing consists of adding an entry in the routing table. -If the redirect is towards an Intermediate System, then an entry is -made in the routing table as well. -The entry in the routing table will mark the -.Tn NSAP -address contained in the redirect -.Tn PDU -as the gateway for the destination -system (if an NET is supplied), or will create a route with -the NSAP address as the -destination and the -.Tn SNPA -address (embodied as a link-level sockaddr) as the -gateway. -.Pp -If the System is configured as an End System, it will report all the -.Tn NSAP Ns s -that have been configured using the ifconfig command, and no others. -It is possible to have more than one -.Tn NSAP -assigned to a given interface, -and it is also possible to have the same -.Tn NSAP -assigned to multiple -interfaces. -However, any -.Tn NSAP -containing an NSEL that is consistent with the -nsellength option (default one) of any interface will be accepted as -an -.Tn NSAP -for this System. -.Sh INTERMEDIATE SYSTEM OPERATION -When an interface requests a mapping for an address not in the routing table, -an error is returned. -.Pp -When an -.Tn NPDU -is forwarded out on the same interface that the -.Tn NPDU -arrived upon, -a redirect -.Tn PDU -is generated. -.Sh MANUAL ROUTING TABLE MODIFICATION -To facilitate communications with systems which do not use -.Nm ES-IS , -one may add a route whose destination is a sockaddr_iso containing -the -.Tn NSAP -in question, and the gateway being a link-level sockaddr, -either by writing a special purpose program, or using the -.Xr route 8 -command e.g.: -.Bd -literal -route add -iface -osi 49.0.4.8.0.2b.b.83.bf -link qe0:8.0.2b.b.83.bf -.Ed -.Pp -If the -System is configured as an End System and has a single network interface -which does not support multicast reception, -it is necessary to manually configure the location of an -.Tn IS , -using the route command in a similar way. -There, the destination address should be -.Dq default -(spelled -out literally as 7 -.Tn ASCII -characters), and the gateway should be -once again be a link-level sockaddr specifying the -.Tn SNPA -of the -.Tn IS . -.Sh SEE ALSO -.Xr iso 4 , -.Xr ifconfig 8 , -.Xr route 8 -.Rs -.%T "End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service" -.%R ISO -.%N 9542 -.Re -.Sh BUGS -Redirect -.Tn PDU Ns s -do not contain options from the forwarded -.Tn NPDU -which generated -the redirect. -The multicast address used on the 802.3 network is taken from the -.Tn NBS -December 1987 agreements. -This multicast address is not compatible with the 802.5 (Token Ring) -multicast addresses format. -Therefore, broadcast addresses are used on the 802.5 subnetwork. -Researchers at the University of Wisconsin are constructing an implementation -of the -.Tn IS-IS -routing protocol. diff --git a/share/man/man4/iso.4 b/share/man/man4/iso.4 deleted file mode 100644 index ae2b220704c..00000000000 --- a/share/man/man4/iso.4 +++ /dev/null @@ -1,184 +0,0 @@ -.\" $OpenBSD: iso.4,v 1.11 2003/06/02 23:30:12 millert Exp $ -.\" $NetBSD: iso.4,v 1.3 1994/11/30 16:22:20 jtc Exp $ -.\" -.\" Copyright (c) 1990, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 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. 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 -.\" SUCH DAMAGE. -.\" -.\" @(#)iso.4 8.2 (Berkeley) 11/30/93 -.\" -.Dd November 30, 1993 -.Dt ISO 4 -.Os -.Sh NAME -.Nm iso -.Nd ISO protocol family -.Sh SYNOPSIS -.Fd #include <sys/types.h> -.Fd #include <netiso/iso.h> -.Sh DESCRIPTION -The -.Tn ISO -protocol family is a collection of protocols -that uses the -.Tn ISO -address format. -The -.Tn ISO -family provides protocol support for the -.Dv SOCK_SEQPACKET -abstraction through the -.Tn TP -protocol -.Pf ( Tn ISO -8073), -for the -.Dv SOCK_DGRAM -abstraction through the connectionless transport -protocol -.Pf ( Tn ISO -8602), -and for the -.Dv SOCK_RAW -abstraction -by providing direct access (for debugging) to the -.Tn CLNP -.Pf ( Tn ISO -8473) network layer protocol. -.Sh ADDRESSING -.Tn ISO -addresses are based upon -.Tn ISO -8348/AD2, -.Rs -.%T "Addendum to the Network Service Definition Covering Network Layer Addressing" -.Re -.Pp -Sockets bound to the OSI protocol family use -the following address structure: -.Bd -literal -struct iso_addr { - u_char isoa_len; /* length, not including this byte */ - char isoa_genaddr[20]; /* general opaque address */ -}; - -struct sockaddr_iso { - u_char siso_len; /* size of this sockaddr */ - u_char siso_family; /* addressing domain, AF_ISO */ - u_char siso_plen; /* presentation selector length */ - u_char siso_slen; /* session selector length */ - u_char siso_tlen; /* transport selector length */ - struct iso_addr siso_addr; /* network address */ - u_char siso_pad[6]; /* space for gosip v2 SELs */ -}; -#define siso_nlen siso_addr.isoa_len -#define siso_data siso_addr.isoa_genaddr -.Ed -.Pp -The fields of this structure are: -.Bl -tag -width Ds -.It Ar siso_len : -Length of the entire address structure, in bytes, which may grow to -be longer than the 32 bytes shown above. -.It Ar siso_family : -Identifies the domain: -.Dv AF_ISO . -.It Ar siso_tlen : -Length of the transport selector. -.It Ar siso_slen : -Length of the session selector. -This is not currently supported by the kernel and is provided as -a convenience for user level programs. -.It Ar siso_plen : -Length of the presentation selector. -This is not currently supported by the kernel and is provided as -a convenience for user level programs. -.It Ar siso_addr : -The network part of the address, described below. -.El -.Sh TRANSPORT ADDRESSING -An -.Tn ISO -transport address is similar to an Internet address in that -it contains a network-address portion and a portion that the -transport layer uses to multiplex its services among clients. -In the Internet domain, this portion of the address is called a -.Em port . -In the -.Tn ISO -domain, this is called a -.Em transport selector -(also known at one time as a -.Em transport suffix ) . -While ports are always 16 bits, -transport selectors may be -of (almost) arbitrary size. -.Pp -Since the C language does not provide convenient variable -length structures, we have separated the selector lengths -from the data themselves. -The network address and various selectors are stored contiguously, -with the network address first, then the transport selector, and so -on. -Thus, if you had a network address of less than 20 bytes, -the transport selector would encroach on space normally reserved -for the network address. -.Sh NETWORK ADDRESSING -.Tn ISO -network addresses are limited to 20 bytes in length. -.Tn ISO -network addresses can take any format. -.Sh PROTOCOLS -The -.Tn ARGO -1.0 implementation of the -.Tn ISO -protocol family comprises -the Connectionless-Mode Network Protocol -.Pq Tn CLNP , -and the Transport Protocol -.Pq Tn TP , -classes 4 and 0, -and -.Tn X.25 . -.Tn TP -is used to support the -.Dv SOCK_SEQPACKET -abstraction. -A raw interface to -.Tn CLNP -is available -by creating an -.Tn ISO -socket of type -.Dv SOCK_RAW . -This is used for -.Tn CLNP -debugging only. -.Sh SEE ALSO -.Xr clnp 4 , -.Xr cltp 4 , -.Xr tp 4 diff --git a/share/man/man4/tp.4 b/share/man/man4/tp.4 deleted file mode 100644 index 9d9c390ce90..00000000000 --- a/share/man/man4/tp.4 +++ /dev/null @@ -1,721 +0,0 @@ -.\" $OpenBSD: tp.4,v 1.21 2003/06/06 10:29:41 jmc Exp $ -.\" $NetBSD: tp.4,v 1.4 1994/11/30 16:22:38 jtc Exp $ -.\" -.\" Copyright (c) 1990, 1991, 1993 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 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. 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 -.\" SUCH DAMAGE. -.\" -.\" @(#)tp.4 8.4 (Berkeley) 4/19/94 -.\" -.Dd April 19, 1994 -.Dt TP 4 -.Os -.Sh NAME -.Nm tp -.Nd ISO Transport Protocol -.Sh SYNOPSIS -.Fd #include <sys/socket.h> -.Fd #include <netiso/iso_errno.h> -.Fd #include <netiso/tp_param.h> -.Fd #include <netiso/tp_user.h> -.Ft int -.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0 -.Sh DESCRIPTION -The -.Tn 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 -.Dv SOCK_SEQPACKET -abstraction. -The -.Tn TP -protocol makes use of a standard -.Tn 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. -.Pp -Sockets utilizing the tp protocol are either -.Dq active -or -.Dq passive . -Active sockets initiate connections to passive -sockets. -By default -.Tn TCP -sockets are created active; to create a -passive socket the -.Xr listen 2 -system call must be used -after binding the socket with the -.Xr bind 2 -system call. -Only passive sockets may use the -.Xr accept 2 -call to accept incoming connections. -Only active sockets may use the -.Xr connect 2 -call to initiate connections. -.Pp -Passive sockets may -.Dq underspecify -their location to match -incoming connection requests from multiple networks. -This technique, termed -.Dq wildcard addressing , -allows a single -server to provide service to clients on multiple networks. -To create a socket which listens on all networks, the -.Tn 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. -.Pp -The -.Tn ISO -Transport Protocol implemented for -.Tn AOS R2 -at the University of Wisconsin - Madison, -and modified for inclusion in the Berkeley Software Distribution, -includes classes 0 and 4 -of the -.Tn ISO -transport protocols -as specified in -the June 1986 version of -.Tn 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 "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 -.Tn ISO -domain. -Class 4 may be used in the Internet domain as well as in the -.Tn ISO -domain. -.Pp -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 -.Pq Dv EOTSDU -indication, and for the receipt and transmission of user -connect, confirm, and disconnect data. -See -.Xr sendmsg 2 -and -.Xr recvmsg 2 , -and further discussion -below for the formats of the data in the ancillary data buffer. -If the -.Dv EOTSDU -is not needed, the normal -.Xr read 2 , -and -.Xr write 2 -system calls may be used. -.Pp -Through the -.Xr getsockopt 2 -and -.Xr setsockopt 2 -system calls, -.Tn TP -supports several options -to control such things as negotiable options -in the protocol and protocol strategies. -The options are defined in -.Aq Pa netiso/tp_user.h , -and are described below. -.Pp -In the tables below, -the options marked with a pound sign -.Ql \&# -may be used -with -.Xr setsockopt 2 -after a connection is established. -Others must be used before the connection -is established, in other words, -before calling -.Xr connect 2 -or -.Xr accept 2 . -All options may be used -with -.Xr getsockopt 2 -before or -after a connection is established. -.Bl -tag -width TPOPT_PSTATISTICS -.It Dv TPOPT_CONN_DATA -(char *) [none] -.br -Data to send on -.Xr connect 2 . -The passive user may issue a -.Xr getsockopt 2 -call to retrieve a connection request's user data, -after having done the -.Xr accept 2 -system call without implying confirmation of the connection. -.Pp -The data may also be retrieved by issuing a -.Xr recvmsg 2 -request for ancillary data only, -without implying confirmation of the connection. -The returned -.Va cmsghdr -will contain -.Dv SOL_TRANSPORT -for the -.Va csmg_level -and -.Dv TPOPT_CONN_DATA -for -.Va cmsg_type . -.It Dv TPOPT_DISC_DATA \&# -(char *) [none] -.br -Data to send on -.Xr close 2 . -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 -.Xr close 2 . -This may be sent by a -.Xr setsockopt 2 -system call, or by issuing a -.Xr sendmsg 2 -request specifying ancillary data only. -The user-provided -.Va cmsghdr -must contain -.Dv SOL_TRANSPORT -for -.Va csmg_level -and -.Dv TPOPT_DISC_DATA -for -.Va cmsg_type . -Sending of disconnect data will in of itself tear down (or reject) -the connection. -.It Dv TPOPT_CFRM_DATA \&# -(char *) [none] -.br -Data to send when confirming a connection. -This may also be sent by a -.Xr setsockopt 2 -system call, or by issuing a -.Xr sendmsg 2 -request, as above. -Sending of connect confirm data will cause the connection -to be confirmed rather than rejected. -.It Dv TPOPT_PERF_MEAS \&# -Boolean. -.br -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 -.Tn ARGO -implementation, this will cause performance measurement to be -turned -on the passive side as well. -.\" See -.\" .Xr tpperf 8 . -.It Dv TPOPT_PSTATISTICS -No associated value on input. -On output, -.Ar struct tp_pmeas . -.Pp -This command is used to read the performance statistics accumulated -during a connection's lifetime. -It can only be used with -.Xr getsockopt 2 . -The structure it returns is described in -.Aq Pa netiso/tp_stat.h . -.\" See -.\" .Xr tpperf 8 . -.It Dv TPOPT_FLAGS -unsigned integer. -[0x0] -.br -This command can only be used with -.Xr getsockopt 2 . -See the description of the flags below. -.It Dv TPOPT_PARAMS -.Ar struct tp_conn_param -.br -Used to get or set group parameters for a connection. -The -.Ar struct tp_conn_param -is the argument used with the -.Xr getsockopt 2 -or -.Xr setsockopt 2 -system call. -It is described in -.Aq Pa netiso/tp_user.h . -.Pp -The fields of the -.Ar tp_conn_param -structure are -described below. -.El -.Pp -.Em Values for TPOPT_PARAMS : -.Bl -tag -width p_sendack_ticks -.It Ar p_Nretrans -nonzero short integer [1] -.br -Number of times a TPDU -will be retransmitted before the -local TP entity closes a connection. -.It Ar p_dr_ticks -nonzero short integer [various] -.br -Number of clock ticks between retransmissions of disconnect request -TPDUs. -.It Ar p_dt_ticks -nonzero short integer [various] -.br -Number of clock ticks between retransmissions of data -TPDUs. -This parameter applies only to class 4. -.It Ar p_cr_ticks -nonzero short integer [various] -.br -Number of clock ticks between retransmissions of connection request -TPDUs. -.It Ar p_cc_ticks -nonzero short integer [various] -.br -Number of clock ticks between retransmissions of connection confirm -TPDUs. -This parameter applies only to class 4. -.It Ar p_x_ticks -nonzero short integer [various] -.br -Number of clock ticks between retransmissions of expedited data -TPDUs. -This parameter applies only to class 4. -.It Ar p_sendack_ticks -nonzero short integer [various] -.br -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 -.Dv TPACK_EACH ) . -This parameter applies only to class 4. -.It Ar p_ref_ticks -nonzero short integer [various] -.br -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 -.Tn ARGO -implementation, despite the fact that -the frozen reference function is required only for -class 4. -.It Ar p_inact_ticks -nonzero short integer [various] -.br -Number of clock ticks without an incoming packet from the peer after which -.Tn TP -close the connection. -This parameter applies only to class 4. -.It Ar p_keepalive_ticks -nonzero short integer [various] -.br -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. -.It Ar p_winsize -short integer between 128 and 16384. -[4096 bytes] -.br -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. -.It Ar p_tpdusize -unsigned char between 0x7 and 0xd. -[0xc for class 4] [0xb for class 0] -.br -Log 2 of the maximum TPDU size to be negotiated. -The -.Tn TP -standard -.Pf ( Tn ISO -8473) gives an upper bound of -0xd for class 4 and 0xb for class 0. -The -.Tn ARGO -implementation places upper bounds of -0xc on class 4 and 0xb on class 0. -.It Ar p_ack_strat -.Dv TPACK_EACH -or -.Dv TPACK_WINDOW . -.Bq Dv TPACK_WINDOW -.br -This parameter applies only to class 4. -Two acknowledgment strategies are supported: -.Pp -.Dv TPACK_EACH means that each data TPDU -is acknowledged -with an AK TPDU. -.Pp -.Dv TPACK_WINDOW -means that upon receipt of the packet that represents -the high edge of the last window advertised, an AK TPDU is generated. -.It Ar p_rx_strat -4 bit mask -.Bq Dv TPRX_USE_CW No \&|\ Dv TPRX_FASTSTART -over -connectionless network protocols] -.Pf [ Dv TPRX_USE_CW -over -connection-oriented network protocols] -.br -This parameter applies only to class 4. -The bit mask may include the following values: -.Pp -.Dv TPRX_EACH : -When a retransmission timer expires, retransmit -each packet in the send window rather than -just the first unacknowledged packet. -.Pp -.Dv 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. -.Pp -.Dv 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. -.It Ar p_class -5 bit mask -.Bq Dv TP_CLASS_4 No \&|\ Dv TP_CLASS_0 -.br -Bit mask including one or both of the values -.Dv TP_CLASS_4 -and -.Dv TP_CLASS_0 . -The higher class indicated is the preferred class. -If only one class is indicated, negotiation will not occur -during connection establishment. -.It Ar p_xtd_format -Boolean. -[false] -.br -Boolean indicating that extended format is negotiated. -This parameter applies only to class 4. -.It Ar p_xpd_service -Boolean. -[true] -.br -Boolean indicating that -the expedited data transport service will be negotiated. -This parameter applies only to class 4. -.It Ar p_use_checksum -Boolean. -[true] -.br -Boolean indicating the use of checksums will be negotiated. -This parameter applies only to class 4. -.It Ar p_use_nxpd -Reserved for future use. -.It Ar p_use_rcc -Reserved for future use. -.It Ar p_use_efc -Reserved for future use. -.It Ar p_no_disc_indications -Boolean. -[false] -.Pp -Boolean indicating that the local -.Tn TP -entity will not issue -indications (signals) when a -.Tn TP -connection is disconnected. -.It Ar p_dont_change_params -Boolean. -[false] -.br -If -.Em true -the -.Tn TP -entity will not override -any of the other values given in this structure. -If the values cannot be used, the -.Tn TP -entity will drop, disconnect, -or refuse to establish the connection to which this structure pertains. -.It Ar p_netservice -One of { -.Dv ISO_CLNS , -.Dv ISO_CONS , -.Dv ISO_COSNS , -.Dv IN_CLNS } . -.Pf [ Dv ISO_CLNS ] -.br -Indicates which network service is to be used. -.Pp -.Dv ISO_CLNS -indicates the connectionless network service provided -by CLNP -.Pf ( Tn ISO -8473). -.Pp -.Dv ISO_CONS -indicates the connection-oriented network service provided -by X.25 -.Pf ( Tn ISO -8208) and -.Tn ISO -8878. -.Pp -.Dv ISO_COSNS -indicates the -connectionless network service running over a -connection-oriented subnetwork service: CLNP -.Pf ( Tn ISO -8473) over X.25 -.Pf ( Tn ISO -8208). -.Pp -.Dv IN_CLNS -indicates the -DARPA Internet connectionless network service provided by IP (RFC 791). -.It Ar p_dummy -Reserved for future use. -.El -.Pp -The -.Dv 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. -.sp 1 -.Em Values for TPOPT_FLAGS : -.Bl -tag -width Bitsx -.It Sy Bits -.Sy Description [Default] -.It \&0 -.Dv TPFLAG_NLQOS_PDN : -set when the quality of the -network service is -similar to that of a public data network. -.It \&1 -.Dv TPFLAG_PEER_ON_SAMENET : -set when the peer -.Tn TP -entity -is considered to be on the same network as the local -.Tn TP -entity. -.It \&2 -Not used. -.It \&3 -.Dv TPFLAG_XPD_PRES : -set when expedited data are present. -[0] -.It 4\&..7 -Reserved. -.El -.Sh ERRORS -The -.Tn TP -entity returns -.Va errno -error values as defined in -.Aq Pa sys/errno.h -and -.Aq Pa netiso/iso_errno.h . -.\" User programs may print messages associated with these value by -.\" using an expanded version of -.\" .Xr perror 3 -.\" found in the -.\" .Tn ISO -.\" library, -.\" .Pa libisodir.a . -.br -.Pp -If the -.Tn 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 -.Tn TP -entity issues a -.Dv 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 -.Va errno -value upon return from the system call is -.Er EINTR . -If the signal -.Dv SIGURG -is being handled by reading -from the socket, and it was an -.Xr accept 2 -that -timed out, the read may result in -.Er ENOTSOCK , -because the -.Xr accept 2 -call had not yet returned a -legitimate socket descriptor when the signal was handled. -.Dv ETIMEDOUT -(or some other -.Va errno -value appropriate to the type of error) is returned if -.Dv SIGURG -is blocked -for the duration of the system call. -A user program should take one of the following approaches: -.Bl -tag -width Ds -.It Block Dv SIGURG -If the program is servicing -only one connection, it can block or ignore -.Dv SIGURG -during connection -establishment. -The advantage of this is that the -.Va 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. -.It Handle Dv 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 -.Dv SIGURG . -It can use the -.Fn 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, -.Xr getsockopt 2 -will return -.Er ENOTCONN . -.El -.Sh SEE ALSO -.Xr netstat 1 , -.Xr clnp 4 , -.Xr cltp 4 , -.Xr iso 4 , -.Xr tcp 4 , -.Xr ifconfig 8 -.Sh BUGS -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, so it is not possible for a -.Tn TP -entity to inform its peer -that "I received your expedited data but have no room to receive more." -The -.Tn TP -entity has the choice of acknowledging receipt of the -XPD TPDU: -.Bl -tag -width Ds -.It "when the user receives the" XPD TSDU -which may be a fairly long time, -which may cause the sending -.Tn TP -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 -.Dq soon , -the expedited data will not be acknowledged (until the -receiving user receives the first XPD TSDU). -.El -.Pp -The -.Tn 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. |