spp - Xerox Sequenced Packet Protocol
#include <sys/socket.h>
#include <netns/ns.h>
#include <netns/sp.h>
int
socket(AF_NS, SOCK_STREAM, 0);
int
socket(AF_NS, SOCK_SEQPACKET, 0);
The SPP protocol provides a reliable, flow-controlled, twoway transmission
of data. It is a byte-stream protocol used to support
the
SOCK_STREAM abstraction. SPP uses the standard NS(tm) address formats.
Sockets utilizing the SPP protocol are either ``active'' or
``passive''.
Active sockets initiate connections to passive sockets. By
default SPP
sockets are created active; to create a passive socket the
listen(2) system
call must be used after binding the socket with the
bind(2) system
call. Only passive sockets may use the accept(2) call to
accept incoming
connections. Only active sockets may use the connect(2)
call to initiate
connections.
Passive sockets may ``underspecify'' their location to match
incoming
connection requests from multiple networks. This technique,
termed
``wildcard addressing'', allows a single server to provide
service to
clients on multiple networks. To create a socket which listens on all
networks, the NS address of all zeroes must be bound. The
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 to
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.
If the SOCK_SEQPACKET socket type is specified, each packet
received has
the actual 12 byte sequenced packet header left for the user
to inspect:
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;
};
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.
For either socket type, packets received with the Attention
bit sent are
interpreted as out of band data. Data sent with ``send(...,
..., ...,
MSG_OOB'') cause the attention bit to be set.
A socket operation may fail with one of the following errors
returned:
[EISCONN] when trying to establish a connection on a
socket which
already has one;
[ENOBUFS] when the system runs out of memory for an
internal data
structure;
[ETIMEDOUT] when a connection was dropped due to excessive retransmissions;
[ECONNRESET] when the remote peer forces the connection
to be closed;
[ECONNREFUSED] when the remote peer actively refuses connection establishment
(usually because no process is
listening to the
port);
[EADDRINUSE] when an attempt is made to create a socket
with a port
which has already been allocated;
[EADDRNOTAVAIL] when an attempt is made to create a socket
with a network
address for which no network interface
exists.
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.
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 XEROX
product internetwork router. The data
argument for
the setsockopt call must be an unsigned
short.
netintro(4), ns(4)
The spp protocol appeared in 4.3BSD.
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.
OpenBSD 3.6 April 19, 1994
[ Back ] | 