summaryrefslogtreecommitdiffstats
path: root/share
diff options
context:
space:
mode:
authormpp <mpp@FreeBSD.org>1997-01-30 23:51:48 +0000
committermpp <mpp@FreeBSD.org>1997-01-30 23:51:48 +0000
commit7baf285865adcd9880eda4b727fa8a7ea42a4670 (patch)
treef08c2fe3627fbc1fa4c0c816371e8ecd42f71f84 /share
parent2a174308fef7b820bcda7a0bff9ee406254cef68 (diff)
downloadFreeBSD-src-7baf285865adcd9880eda4b727fa8a7ea42a4670.zip
FreeBSD-src-7baf285865adcd9880eda4b727fa8a7ea42a4670.tar.gz
Actually remove the old netns/netiso man pages. They haven't
been installed for the last 9 months or so anyways.
Diffstat (limited to 'share')
-rw-r--r--share/man/man4/Makefile2
-rw-r--r--share/man/man4/clnp.4168
-rw-r--r--share/man/man4/cltp.4128
-rw-r--r--share/man/man4/esis.4216
-rw-r--r--share/man/man4/idp.4186
-rw-r--r--share/man/man4/iso.4187
-rw-r--r--share/man/man4/ns.4180
-rw-r--r--share/man/man4/nsip.4128
-rw-r--r--share/man/man4/spp.4191
-rw-r--r--share/man/man4/tp.4723
10 files changed, 0 insertions, 2109 deletions
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 <sys/socket.h>
-.Fd #include <netiso/iso.h>
-.Fd #include <netiso/clnp.h>
-.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 <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
-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 <sys/socket.h>
-.Fd #include <netns/ns.h>
-.Fd #include <netns/idp.h>
-.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 <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,
-.%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 <netns/ns_if.h>
-.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 <sys/socket.h>
-.Fd #include <netns/ns.h>
-.Fd #include <netns/sp.h>
-.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 <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
-.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.
OpenPOWER on IntegriCloud