|
|
1.1 root 1: .\" Copyright (c) 1985 The Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted provided
5: .\" that: (1) source distributions retain this entire copyright notice and
6: .\" comment, and (2) distributions including binaries display the following
7: .\" acknowledgement: ``This product includes software developed by the
8: .\" University of California, Berkeley and its contributors'' in the
9: .\" documentation or other materials provided with the distribution and in
10: .\" all advertising materials mentioning features or use of this software.
11: .\" Neither the name of the University nor the names of its contributors may
12: .\" be used to endorse or promote products derived from this software without
13: .\" specific prior written permission.
14: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
15: .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
16: .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
17: .\"
18: .\" @(#)spp.4 1.4 (Berkeley) 6/23/90
19: .\"
20: .TH SPP 4 "June 23, 1990"
21: .UC 6
22: .SH NAME
23: spp \- Xerox Sequenced Packet Protocol
24: .SH SYNOPSIS
25: .B #include <sys/socket.h>
26: .br
27: .B #include <netns/ns.h>
28: .br
29: .B s = socket(AF_NS, SOCK_STREAM, 0);
30: .PP
31: .B #include <netns/sp.h>
32: .br
33: .B s = socket(AF_NS, SOCK_SEQPACKET, 0);
34: .SH DESCRIPTION
35: The SPP protocol provides reliable, flow-controlled, two-way
36: transmission of data. It is a byte-stream protocol used to
37: support the SOCK_STREAM abstraction. SPP uses the standard
38: NS(tm) address formats.
39: .PP
40: Sockets utilizing the SPP protocol are either \*(lqactive\*(rq or
41: \*(lqpassive\*(rq. Active sockets initiate connections to passive
42: sockets. By default SPP sockets are created active; to create a
43: passive socket the
44: .IR listen (2)
45: system call must be used
46: after binding the socket with the
47: .IR bind (2)
48: system call. Only
49: passive sockets may use the
50: .IR accept (2)
51: call to accept incoming connections. Only active sockets may
52: use the
53: .IR connect (2)
54: call to initiate connections.
55: .PP
56: Passive sockets may \*(lqunderspecify\*(rq their location to match
57: incoming connection requests from multiple networks. This
58: technique, termed \*(lqwildcard addressing\*(rq, allows a single
59: server to provide service to clients on multiple networks.
60: To create a socket which listens on all networks, the NS
61: address of all zeroes must be bound.
62: The SPP port may still be specified
63: at this time; if the port is not specified the system will assign one.
64: Once a connection has been established the socket's address is
65: fixed by the peer entity's location. The address assigned the
66: socket is the address associated with the network interface
67: through which packets are being transmitted and received. Normally
68: this address corresponds to the peer entity's network.
69: .LP
70: If the SOCK_SEQPACKET socket type is specified,
71: each packet received has the actual 12 byte sequenced packet header
72: left for the user to inspect:
73: .nf
74: struct sphdr {
75: u_char sp_cc; /* \fIconnection control\fP */
76: #define SP_EM 0x10 /* \fIend of message\fP */
77: u_char sp_dt; /* \fIdatastream type\fP */
78: u_short sp_sid;
79: u_short sp_did;
80: u_short sp_seq;
81: u_short sp_ack;
82: u_short sp_alo;
83: };
84: .fi
85: This facilitates the implementation of higher level Xerox protocols
86: which make use of the data stream type field and the end of message bit.
87: Conversely, the user is required to supply a 12 byte header,
88: the only part of which inspected is the data stream type and end of message
89: fields.
90: .LP
91: For either socket type,
92: packets received with the Attention bit sent are interpreted as
93: out of band data. Data sent with send(..., ..., ..., MSG_OOB)
94: cause the attention bit to be set.
95: .SH DIAGNOSTICS
96: A socket operation may fail with one of the following errors returned:
97: .TP 20
98: [EISCONN]
99: when trying to establish a connection on a socket which
100: already has one;
101: .TP 20
102: [ENOBUFS]
103: when the system runs out of memory for
104: an internal data structure;
105: .TP 20
106: [ETIMEDOUT]
107: when a connection was dropped
108: due to excessive retransmissions;
109: .TP 20
110: [ECONNRESET]
111: when the remote peer
112: forces the connection to be closed;
113: .TP 20
114: [ECONNREFUSED]
115: when the remote
116: peer actively refuses connection establishment (usually because
117: no process is listening to the port);
118: .TP 20
119: [EADDRINUSE]
120: when an attempt
121: is made to create a socket with a port which has already been
122: allocated;
123: .TP 20
124: [EADDRNOTAVAIL]
125: when an attempt is made to create a
126: socket with a network address for which no network interface
127: exists.
128: .SH SOCKET OPTIONS
129: .TP 20
130: SO_DEFAULT_HEADERS
131: when set, this determines the data stream type and whether
132: the end of message bit is to be set on every ensuing packet.
133: .TP 20
134: SO_MTU
135: This specifies the maximum ammount of user data in a single packet.
136: The default is 576 bytes - sizeof(struct spidp). This quantity
137: affects windowing -- increasing it without increasing the amount
138: of buffering in the socket will lower the number of unread packets
139: accepted. Anything larger than the default will not be forwarded
140: by a bona fide XEROX product internetwork router.
141: The data argument for the setsockopt call must be
142: an unsigned short.
143: .SH SEE ALSO
144: intro(4), ns(4)
145: .SH BUGS
146: There should be some way to reflect record boundaries in
147: a stream.
148: For stream mode, there should be an option to get the data stream type of
149: the record the user process is about to receive.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.