192 lines
6.2 KiB
Groff
192 lines
6.2 KiB
Groff
.\" 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.
|