From 7baf285865adcd9880eda4b727fa8a7ea42a4670 Mon Sep 17 00:00:00 2001 From: mpp Date: Thu, 30 Jan 1997 23:51:48 +0000 Subject: Actually remove the old netns/netiso man pages. They haven't been installed for the last 9 months or so anyways. --- share/man/man4/Makefile | 2 - share/man/man4/clnp.4 | 168 ----------- share/man/man4/cltp.4 | 128 --------- share/man/man4/esis.4 | 216 --------------- share/man/man4/idp.4 | 186 ------------- share/man/man4/iso.4 | 187 ------------- share/man/man4/ns.4 | 180 ------------ share/man/man4/nsip.4 | 128 --------- share/man/man4/spp.4 | 191 ------------- share/man/man4/tp.4 | 723 ------------------------------------------------ 10 files changed, 2109 deletions(-) delete mode 100644 share/man/man4/clnp.4 delete mode 100644 share/man/man4/cltp.4 delete mode 100644 share/man/man4/esis.4 delete mode 100644 share/man/man4/idp.4 delete mode 100644 share/man/man4/iso.4 delete mode 100644 share/man/man4/ns.4 delete mode 100644 share/man/man4/nsip.4 delete mode 100644 share/man/man4/spp.4 delete mode 100644 share/man/man4/tp.4 (limited to 'share') diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile index 21907eb..eeb0e1c 100644 --- a/share/man/man4/Makefile +++ b/share/man/man4/Makefile @@ -8,8 +8,6 @@ MAN4= bpf.4 ccd.4 cd.4 ch.4 ddb.4 divert.4 drum.4 fd.4 fpa.4 \ ttcp.4 termios.4 tty.4 udp.4 uk.4 update.4 unix.4 worm.4 yp.4 \ zero.4 -# not installed: clnp.4 cltp.4 esis.4 idp.4 iso.4 ns.4 nsip.4 spp.4 tp.4 - MLINKS+=fd.4 stderr.4 fd.4 stdin.4 fd.4 stdout.4 MLINKS+=netintro.4 networking.4 MLINKS+=ipfirewall.4 ipacct.4 ipfirewall.4 ipfw.4 ipfirewall.4 ipaccounting.4 diff --git a/share/man/man4/clnp.4 b/share/man/man4/clnp.4 deleted file mode 100644 index 1e1ce12..0000000 --- a/share/man/man4/clnp.4 +++ /dev/null @@ -1,168 +0,0 @@ -.\" 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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 -.\" $FreeBSD$ -.\" -.Dd April 2, 1994 -.Dt CLNP 4 -.Os -.Sh NAME -.Nm clnp -.Nd Connectionless-Mode Network Protocol -.Sh SYNOPSIS -.Fd #include -.Fd #include -.Fd #include -.Ft int -.Fn socket AF_ISO SOCK_RAW 0 -.Sh DESCRIPTION -.Tn CLNP -is the connectionless-mode network protocol used by the -connectionless-mode network service. This protocol is specified in -.Tn ISO -8473. -It may be accessed -through a -.Dq raw socket -for debugging purposes only. -.Tn CLNP -sockets are connectionless, -and are normally used with the -.Xr sendto -and -.Xr recvfrom -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 -.Tn CLNP -header prepended to -them. Incoming packets received by the user contain the full -.Tn CLNP -header. -The following -.Xr setsockopt -options apply to -.Tn 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 -.Tn CLNP -checksum -.El -.Pp -.It Dv CLNPOPT_OPTS -Sets -.Tn CLNP -options. The options must be formatted exactly as specified by -.Tn 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 intro 4 , -.Xr iso 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 -.Tn 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 045816e..0000000 --- a/share/man/man4/cltp.4 +++ /dev/null @@ -1,128 +0,0 @@ -.\" 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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 -.\" $FreeBSD$ -.\" -.Dd June 9, 1993 -.Dt CLTP 4 -.Os -.Sh NAME -.Nm cltp -.Nd -.Tn ISO -Connectionless Transport Protocol -.Sh SYNOPSIS -.Fd #include -.Fd #include -.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 -and -.Xr recvfrom -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 intro 4 , -.Xr iso 4 diff --git a/share/man/man4/esis.4 b/share/man/man4/esis.4 deleted file mode 100644 index 49d0830..0000000 --- a/share/man/man4/esis.4 +++ /dev/null @@ -1,216 +0,0 @@ -.\" 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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 -.\" $FreeBSD$ -.\" -.Dd November 30, 1993 -.Dt ESIS 4 -.Os -.Sh NAME -.Nm esis -.Nd End System to Intermediate System Routing Protocol -.Sh SYNOPSIS -.Sy pseudo-device -.Nm ether -.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 -.Pp -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 un 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/idp.4 b/share/man/man4/idp.4 deleted file mode 100644 index 82ed034..0000000 --- a/share/man/man4/idp.4 +++ /dev/null @@ -1,186 +0,0 @@ -.\" Copyright (c) 1985, 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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. -.\" -.\" @(#)idp.4 8.1 (Berkeley) 6/5/93 -.\" $FreeBSD$ -.\" -.Dd June 5, 1993 -.Dt IDP 4 -.Os BSD 4.3 -.Sh NAME -.Nm idp -.Nd Xerox Internet Datagram Protocol -.Sh SYNOPSIS -.Fd #include -.Fd #include -.Fd #include -.Ft int -.Fn socket AF_NS SOCK_DGRAM 0 -.Sh DESCRIPTION -.Tn IDP -is a simple, unreliable datagram protocol which is used -to support the -.Dv SOCK_DGRAM -abstraction for the Internet -protocol family. -.Tn IDP -sockets are connectionless, and are -normally used with the -.Xr sendto -and -.Xr recvfrom -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 -Xerox protocols are built vertically on top of -.Tn IDP . -Thus, -.Tn IDP -address formats are identical to those used by -.Tn SPP . -Note that the -.Tn IDP -port -space is the same as the -.Tn SPP -port space (i.e. a -.Tn IDP -port -may be -.Dq connected -to a -.Tn SPP -port, with certain -options enabled below). -In addition broadcast packets may be sent -(assuming the underlying network supports -this) by using a reserved -.Dq broadcast address ; -this address -is network interface dependent. -.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 port 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 SOCKET OPTIONS -.Bl -tag -width [SO_HEADERS_ON_OUTPUT] -.It Bq Dv SO_ALL_PACKETS -When set, this option defeats automatic processing of Error packets, -and Sequence Protocol packets. -.It Bq Dv SO_DEFAULT_HEADERS -The user provides the kernel an -.Tn IDP -header, from which -it gleans the Packet Type. -When requested, the kernel will provide an -.Tn IDP -header, showing -the default packet type, and local and foreign addresses, if -connected. -.It Bq Dv SO_HEADERS_ON_INPUT -When set, the first 30 bytes of any data returned from a read -or recv from will be the initial 30 bytes of the -.Tn IDP -packet, -as described by -.Bd -literal -offset indent -struct idp { - u_short idp_sum; - u_short idp_len; - u_char idp_tc; - u_char idp_pt; - struct ns_addr idp_dna; - struct ns_addr idp_sna; -}; -.Ed -.Pp -This allows the user to determine the packet type, and whether -the packet was a multi-cast packet or directed specifically at -the local host. -When requested, gives the current state of the option, -.Pf ( Dv NSP_RAWIN -or 0). -.It Bq Dv SO_HEADERS_ON_OUTPUT -When set, the first 30 bytes of any data sent -will be the initial 30 bytes of the -.Tn IDP -packet. -This allows the user to determine the packet type, and whether -the packet should be multi-cast packet or directed specifically at -the local host. -You can also misrepresent the sender of the packet. -When requested, gives the current state of the option. -.Pf ( Dv NSP_RAWOUT -or 0). -.It Bq Dv SO_SEQNO -When requested, this returns a sequence number which is not likely -to be repeated until the machine crashes or a very long time has passed. -It is useful in constructing Packet Exchange Protocol packets. -.El -.Sh SEE ALSO -.Xr recv 2 , -.Xr send 2 , -.Xr intro 4 , -.Xr ns 4 -.Sh HISTORY -The -.Nm -protocol appeared in -.Bx 4.3 . diff --git a/share/man/man4/iso.4 b/share/man/man4/iso.4 deleted file mode 100644 index 858eae7..0000000 --- a/share/man/man4/iso.4 +++ /dev/null @@ -1,187 +0,0 @@ -.\" 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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 -.\" $FreeBSD$ -.\" -.Dd November 30, 1993 -.Dt ISO 4 -.Os -.Sh NAME -.Nm iso -.Nd -.Tn ISO -protocol family -.Sh SYNOPSIS -.Fd #include -.Fd #include -.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, -.%T "Addendum to the Network Service Definition Covering Network Layer Addressing." -.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 -.Pp -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 then 20 bytes, -the transport selector would encroach on space normally reserved -for the network address. -.Pp -.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/ns.4 b/share/man/man4/ns.4 deleted file mode 100644 index 2bc50f4..0000000 --- a/share/man/man4/ns.4 +++ /dev/null @@ -1,180 +0,0 @@ -.\" Copyright (c) 1985, 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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. -.\" -.\" @(#)ns.4 8.2 (Berkeley) 11/30/93 -.\" $FreeBSD$ -.\" -.Dd November 30, 1993 -.Dt NS 4 -.Os BSD 4.3 -.Sh NAME -.Nm ns -.Nd Xerox Network Systems(tm) protocol family -.Sh SYNOPSIS -.Nm options NS -.Nm options NSIP -.Nm pseudo-device ns -.Sh DESCRIPTION -The -.Tn NS -protocol family is a collection of protocols -layered atop the -.Em Internet Datagram Protocol -.Pq Tn IDP -transport layer, and using the Xerox -.Tn NS -address formats. -The -.Tn NS -family provides protocol support for the -.Dv SOCK_STREAM , SOCK_DGRAM , SOCK_SEQPACKET , -and -.Dv SOCK_RAW -socket types; the -.Dv SOCK_RAW -interface is a debugging tool, allowing you to trace all packets -entering, (or with toggling kernel variable, additionally leaving) the local -host. -.Sh ADDRESSING -.Tn NS -addresses are 12 byte quantities, consisting of a -4 byte Network number, a 6 byte Host number and a 2 byte port number, -all stored in network standard format. -(on the -.Tn VAX -these are word and byte reversed; on the -.Tn SUN -they are not -reversed). The include file -.Aq Pa netns/ns.h -defines the -.Tn NS -address as a structure containing unions (for quicker -comparisons). -.Pp -Sockets in the Internet protocol family use the following -addressing structure: -.Bd -literal -offset indent -struct sockaddr_ns { - short sns_family; - struct ns_addr sns_addr; - char sns_zero[2]; -}; -.Ed -.Pp -where an -.Ar ns_addr -is composed as follows: -.Bd -literal -offset indent -union ns_host { - u_char c_host[6]; - u_short s_host[3]; -}; - -union ns_net { - u_char c_net[4]; - u_short s_net[2]; -}; - -struct ns_addr { - union ns_net x_net; - union ns_host x_host; - u_short x_port; -}; -.Ed -.Pp -Sockets may be created with an address of all zeroes to effect -.Dq wildcard -matching on incoming messages. -The local port address specified in a -.Xr bind 2 -call is restricted to be greater than -.Dv NSPORT_RESERVED -(=3000, in -.Aq Pa netns/ns.h ) -unless the creating process is running -as the super-user, providing a space of protected port numbers. -.Sh PROTOCOLS -The -.Tn NS -protocol family supported by the operating system -is comprised of -the Internet Datagram Protocol -.Pq Tn IDP -.Xr idp 4 , -Error Protocol (available through -.Tn IDP ) , -and -Sequenced Packet Protocol -.Pq Tn SPP -.Xr spp 4 . -.Pp -.Tn SPP -is used to support the -.Dv SOCK_STREAM -and -.Dv SOCK_SEQPACKET -abstraction, -while -.Tn IDP -is used to support the -.Dv SOCK_DGRAM -abstraction. -The Error protocol is responded to by the kernel -to handle and report errors in protocol processing; -it is, however, -only accessible to user programs through heroic actions. -.Sh SEE ALSO -.Xr byteorder 3 , -.Xr gethostbyname 3 , -.Xr getnetent 3 , -.Xr getprotoent 3 , -.Xr getservent 3 , -.Xr intro 3 , -.Xr ns 3 , -.Xr idp 4 , -.Xr intro 4 , -.Xr nsip 4 , -.Xr spp 4 -.Rs -.%T "Internet Transport Protocols" -.%R Xerox Corporation document XSIS -.%N 028112 -.Re -.Rs -.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial" -.Re -.Sh HISTORY -The -.Nm -protocol family -appeared in -.Bx 4.3 . diff --git a/share/man/man4/nsip.4 b/share/man/man4/nsip.4 deleted file mode 100644 index 6d71782..0000000 --- a/share/man/man4/nsip.4 +++ /dev/null @@ -1,128 +0,0 @@ -.\" Copyright (c) 1985, 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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. -.\" -.\" @(#)nsip.4 8.2 (Berkeley) 11/30/93 -.\" -.Dd November 30, 1993 -.Dt NSIP 4 -.Os BSD 4.3 -.Sh NAME -.Nm nsip -.Nd software network interface encapsulating NS packets in IP packets -.Sh SYNOPSIS -.Cd options NSIP -.Fd #include -.Sh DESCRIPTION -The -.Nm nsip -interface is a software mechanism which may be -used to transmit Xerox -.Tn NS Ns (tm) -packets through otherwise uncooperative -networks. -It functions by prepending an -.Tn IP -header, and resubmitting the packet -through the -.Tn UNIX -.Tn IP -machinery. -.Pp -The super-user can advise the operating system of a willing partner -by naming an -.Tn IP -address to be associated with an -.Tn NS -address. -Presently, only specific hosts pairs are allowed, and for each host -pair, an artificial point-to-point interface is constructed. -At some future date, -.Tn IP -broadcast addresses or hosts may be paired -with -.Tn NS -networks or hosts. -.Pp -Specifically, a socket option of -.Dv SO_NSIP_ROUTE -is set on a socket -of family -.Dv AF_NS , -type -.Dv SOCK_DGRAM , -passing the following structure: -.Bd -literal -struct nsip_req { - struct sockaddr rq_ns; /* must be ns format destination */ - struct sockaddr rq_ip; /* must be ip format gateway */ - short rq_flags; -}; -.Ed -.Sh DIAGNOSTICS -.Bl -diag -.It nsip%d: can't handle af%d. -The interface was handed -a message with addresses formatted in an unsuitable address -family; the packet was dropped. -.El -.Sh SEE ALSO -.Xr intro 4 , -.Xr ns 4 -.Sh HISTORY -The -.Nm -interface appeared in -.Bx 4.3 . -.Sh BUGS -It is absurd to have a separate pseudo-device for each pt-to-pt -link. -There is no way to change the -.Tn IP -address for an -.Tn NS -host once the -encapsulation interface is set up. -The request should honor flags of -.Dv RTF_GATEWAY -to indicate -remote networks, and the absence of -.Dv RTF_UP -should be a clue -to remove that partner. -This was intended to postpone the necessity of rewriting reverse -.Tn ARP -for the -.Xr en 4 -device, and to allow passing -.Tn XNS -packets through an -Arpanet-Milnet gateway, to facilitate testing between some co-operating -universities. diff --git a/share/man/man4/spp.4 b/share/man/man4/spp.4 deleted file mode 100644 index d749e2e..0000000 --- a/share/man/man4/spp.4 +++ /dev/null @@ -1,191 +0,0 @@ -.\" Copyright (c) 1985, 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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. -.\" -.\" @(#)spp.4 8.2 (Berkeley) 4/19/94 -.\" -.Dd April 19, 1994 -.Dt SPP 4 -.Os BSD 4.3 -.Sh NAME -.Nm spp -.Nd Xerox Sequenced Packet Protocol -.Sh SYNOPSIS -.Fd #include -.Fd #include -.Fd #include -.Ft int -.Fn socket AF_NS SOCK_STREAM 0 -.Ft int -.Fn socket AF_NS SOCK_SEQPACKET 0 -.Sh DESCRIPTION -The -.Tn SPP -protocol provides reliable, flow-controlled, two-way -transmission of data. It is a byte-stream protocol used to -support the -.Dv SOCK_STREAM -abstraction. -.Tn SPP -uses the standard -.Tn NS Ns (tm) -address formats. -.Pp -Sockets utilizing the -.Tn SPP -protocol are either -.Dq active -or -.Dq passive . -Active sockets initiate connections to passive -sockets. By default -.Tn SPP -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 NS -address of all zeroes must be bound. -The -.Tn SPP -port 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. Normally -this address corresponds to the peer entity's network. -.Pp -If the -.Dv SOCK_SEQPACKET -socket type is specified, -each packet received has the actual 12 byte sequenced packet header -left for the user to inspect: -.Bd -literal -offset indent -struct sphdr { - u_char sp_cc; /* connection control */ -#define SP_EM 0x10 /* end of message */ - u_char sp_dt; /* datastream type */ - u_short sp_sid; - u_short sp_did; - u_short sp_seq; - u_short sp_ack; - u_short sp_alo; -}; -.Ed -.Pp -This facilitates the implementation of higher level Xerox protocols -which make use of the data stream type field and the end of message bit. -Conversely, the user is required to supply a 12 byte header, -the only part of which inspected is the data stream type and end of message -fields. -.Pp -For either socket type, -packets received with the Attention bit sent are interpreted as -out of band data. Data sent with -.Dq send(..., ..., ..., Dv MSG_OOB ) -cause the attention bit to be set. -.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; -.It Bq Er ENOBUFS -when the system runs out of memory for -an internal data structure; -.It Bq Er ETIMEDOUT -when a connection was dropped -due to excessive retransmissions; -.It Bq Er ECONNRESET -when the remote peer -forces the connection to be closed; -.It Bq Er ECONNREFUSED -when the remote -peer actively refuses connection establishment (usually because -no process is listening to the port); -.It Bq Er EADDRINUSE -when an attempt -is made to create a socket with a port 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 SOCKET OPTIONS -.Bl -tag -width SO_DEFAULT_HEADERS -.It Dv SO_DEFAULT_HEADERS -when set, this determines the data stream type and whether -the end of message bit is to be set on every ensuing packet. -.It Dv SO_MTU -This specifies the maximum amount of user data in a single packet. -The default is 576 bytes - sizeof(struct spidp). This quantity -affects windowing \- increasing it without increasing the amount -of buffering in the socket will lower the number of unread packets -accepted. Anything larger than the default will not be forwarded -by a bona fide -.Tn XEROX -product internetwork router. -The data argument for the setsockopt call must be -an unsigned short. -.El -.Sh SEE ALSO -.Xr intro 4 , -.Xr ns 4 -.Sh HISTORY -The -.Nm -protocol appeared in -.Bx 4.3 . -.Sh BUGS -There should be some way to reflect record boundaries in -a stream. -For stream mode, there should be an option to get the data stream type of -the record the user process is about to receive. diff --git a/share/man/man4/tp.4 b/share/man/man4/tp.4 deleted file mode 100644 index d30f410..0000000 --- a/share/man/man4/tp.4 +++ /dev/null @@ -1,723 +0,0 @@ -.\" 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. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. 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 -.\" $FreeBSD$ -.\" -.Dd April 19, 1994 -.Dt TP 4 -.Os -.Sh NAME -.Nm tp -.Nd -.Tn ISO -Transport Protocol -.Sh SYNOPSIS -.Fd #include -.Fd #include -.Fd #include -.Fd #include -.Ft int -.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0 -.Sh DESCRIPTION -.Pp -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 -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 -and -.Xr setsockopt -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 -after a connection is established. -Others must be used before the connection -is established, in other words, -before calling -.Xr connect -or -.Xr accept . -All options may be used -with -.Xr getsockopt -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 . -The passive user may issue a -.Xr getsockopt -call to retrieve a connection request's user data, -after having done the -.Xr accept -system call without implying confirmation of the connection. -.Pp -The data may also be retrieved by issuing a -.Xr recvmsg -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 . -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 . -This may be sent by a -.Xr setsockopt -system call, or by issuing a -.Xr sendmsg -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 -system call, or by issuing a -.Xr sendmsg -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 -.Xr 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 -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 . -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 . -See the description of the flags below. -.It Dv TPOPT_PARAMS -.Ar struct tp_conn_param -.br -Used to get or set a group parameters for a connection. -The -.Ar struct tp_conn_param -is the argument used with the -.Xr getsockopt -or -.Xr setsockopt -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 ERROR VALUES -.Pp -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 -found in the -.Tn ISO -library, -.Pa libisodir.a . -.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 -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 -call had not yet returned a -legitimate socket descriptor when the signal was handled. -.Dv ETIMEDOUT -(or a some other 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 -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 \(*e, where \(*e -depends on the application. -The problem is not of major significance since most applications -do not use transport expedited data. -The problem is this: -the expedited data acknowledgment TPDU -has no field for conveying -credit, thus it is not possible for a -.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. -- cgit v1.1