1SPP(4P) SPP(4P)
2
3
4
6 spp - Xerox Sequenced Packet Protocol
7
9 #include <sys/socket.h>
10 #include <netns/ns.h>
11 s = socket(AF_NS, SOCK_STREAM, 0);
12
13 #include <netns/sp.h>
14 s = socket(AF_NS, SOCK_SEQPACKET, 0);
15
17 The SPP protocol provides reliable, flow-controlled, two-way transmis‐
18 sion of data. It is a byte-stream protocol used to support the
19 SOCK_STREAM abstraction. SPP uses the standard NS(tm) address formats.
20
21 Sockets utilizing the SPP protocol are either “active” or “passive”.
22 Active sockets initiate connections to passive sockets. By default SPP
23 sockets are created active; to create a passive socket the listen(2)
24 system call must be used after binding the socket with the bind(2) sys‐
25 tem call. Only passive sockets may use the accept(2) call to accept
26 incoming connections. Only active sockets may use the connect(2) call
27 to initiate connections.
28
29 Passive sockets may “underspecify” their location to match incoming
30 connection requests from multiple networks. This technique, termed
31 “wildcard addressing”, allows a single server to provide service to
32 clients on multiple networks. To create a socket which listens on all
33 networks, the NS address of all zeroes must be bound. The SPP port may
34 still be specified at this time; if the port is not specified the sys‐
35 tem will assign one. Once a connection has been established the
36 socket's address is fixed by the peer entity's location. The address
37 assigned the socket is the address associated with the network inter‐
38 face through which packets are being transmitted and received. Nor‐
39 mally this address corresponds to the peer entity's network.
40
41 If the SOCK_SEQPACKET socket type is specified, each packet received
42 has the actual 12 byte sequenced packet header left for the user to
43 inspect:
44 struct sphdr {
45 u_char sp_cc; /* connection control */
46 #define SP_EM 0x10 /* end of message */
47 u_char sp_dt; /* datastream type */
48 u_short sp_sid;
49 u_short sp_did;
50 u_short sp_seq;
51 u_short sp_ack;
52 u_short sp_alo;
53 };
54 This facilitates the implementation of higher level Xerox protocols
55 which make use of the data stream type field and the end of message
56 bit. Conversely, the user is required to supply a 12 byte header, the
57 only part of which inspected is the data stream type and end of message
58 fields.
59
60 For either socket type, packets received with the Attention bit sent
61 are interpreted as out of band data. Data sent with send(..., ...,
62 ..., MSG_OOB) cause the attention bit to be set.
63
65 A socket operation may fail with one of the following errors returned:
66
67 [EISCONN] when trying to establish a connection on a socket
68 which already has one;
69
70 [ENOBUFS] when the system runs out of memory for an internal
71 data structure;
72
73 [ETIMEDOUT] when a connection was dropped due to excessive
74 retransmissions;
75
76 [ECONNRESET] when the remote peer forces the connection to be
77 closed;
78
79 [ECONNREFUSED] when the remote peer actively refuses connection
80 establishment (usually because no process is lis‐
81 tening to the port);
82
83 [EADDRINUSE] when an attempt is made to create a socket with a
84 port which has already been allocated;
85
86 [EADDRNOTAVAIL] when an attempt is made to create a socket with a
87 network address for which no network interface
88 exists.
89
91 SO_DEFAULT_HEADERS when set, this determines the data stream type and
92 whether the end of message bit is to be set on
93 every ensuing packet.
94
95 SO_MTU This specifies the maximum ammount of user data in
96 a single packet. The default is 576 bytes -
97 sizeof(struct spidp). This quantity affects win‐
98 dowing -- increasing it without increasing the
99 amount of buffering in the socket will lower the
100 number of unread packets accepted. Anything larger
101 than the default will not be forwarded by a bona
102 fide XEROX product internetwork router. The data
103 argument for the setsockopt call must be an
104 unsigned short.
105
107 intro(4N), ns(4F)
108
110 There should be some way to reflect record boundaries in a stream. For
111 stream mode, there should be an option to get the data stream type of
112 the record the user process is about to receive.
113
114
115
1164.3 Berkeley Distribution July 30, 1985 SPP(4P)