d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Actually remove the old netns/netiso man pages. They haven't

Browse Source 
been installed for the last 9 months or so anyways.
This commit is contained in:
Mike Pritchard 1997-01-30 23:51:48 +00:00
parent 0c3a17466f
commit cb7ecbe37a
10 changed files with 0 additions and 2109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
share/man/man4/Makefile
View File

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

168
share/man/man4/clnp.4
View File

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

128
share/man/man4/cltp.4
View File

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

216
share/man/man4/esis.4
View File

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

186
share/man/man4/idp.4
View File

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

187
share/man/man4/iso.4
View File

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

180
share/man/man4/ns.4
View File

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

128
share/man/man4/nsip.4
View File

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

191
share/man/man4/spp.4
View File

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

723
share/man/man4/tp.4
View File

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