.\" Copyright (c) 1986 Regents of the University of California.
.\" All rights reserved. The Berkeley software License Agreement
.\" specifies the terms and conditions for redistribution.
.\" @(#)5.t 1.2 (Berkeley) %G%
A number of facilities have yet to be discussed. For most users
of the IPC the mechanisms already
described will suffice in constructing distributed
applications. However, others will find the need to utilize some
of the features which we consider in this section.
The stream socket abstraction includes the notion of \*(lqout
of band\*(rq data. Out of band data is a logically independent
transmission channel associated with each pair of connected
stream sockets. Out of band data is delivered to the user
independently of normal data along with the SIGURG signal
(if multiple sockets may have out of band data awaiting
delivery, a \fIselect\fP call may be used to determine those
sockets with such data). A process can set the process group
or process id to be informed by the SIGURG signal via the
appropriate \fIfcntl\fP call, as described below for
In addition to the information passed, a logical mark is placed in
the data stream to indicate the point at which the out
of band data was sent. The remote login and remote shell
applications use this facility to propagate signals between
client and server processes. When a signal is expected to
flush any pending output from the remote process(es), all
data up to the mark in the data stream is discarded.
stream abstraction defines that the out of band data facilities
must support the reliable delivery of at least one
out of band message at a time. This message may contain at least one
byte of data, and at least one message may be pending delivery
to the user at any one time. For communications protocols which
support only in-band signaling (i.e. the urgent data is
delivered in sequence with the normal data), the system extracts
the data from the normal data stream and stores it separately.
This allows users to choose between receiving the urgent data
in order and receiving it out of sequence without having to
buffer all the intervening data. It is not possible
to ``peek'' (via MSG_PEEK) at out of band data.
To send an out of band message the MSG_OOB flag is supplied to
a \fIsend\fP or \fIsendto\fP calls,
while to receive out of band data MSG_OOB should be indicated
when performing a \fIrecvfrom\fP or \fIrecv\fP call.
To find out if the read pointer is currently pointing at
the mark in the data stream, the SIOCATMARK ioctl is provided:
ioctl(s, SIOCATMARK, &yes);
If \fIyes\fP is a 1 on return, the next read will return data
after the mark. Otherwise (assuming out of band data has arrived),
the next read will provide data sent by the client prior
to transmission of the out of band signal. The routine used
in the remote login process to flush output on receipt of an
interrupt or quit signal is shown in Figure 5.
char waste[BUFSIZ], mark;
/* flush local terminal output */
ioctl(1, TIOCFLUSH, (char *)&out);
if (ioctl(rem, SIOCATMARK, &mark) < 0) {
(void) read(rem, waste, sizeof (waste));
if (recv(rem, &mark, 1, MSG_OOB) < 0) {
Figure 5. Flushing terminal i/o on receipt of out of band data.
Interrupt driven socket i/o
The SIGIO signal allows a process to be notified
via a signal when a socket (or more generally, a file
descriptor) has data waiting to be read. Use of
the SIGIO facility requires three steps: First,
the process must set up a SIGIO signal handler
by use of the \fIsignal\fP call. Second,
it must set the process id or process group id which is to receive
notification of pending input to its own process id,
or the process group id of its process group (note that
the default process group of a socket is group zero).
This is accomplished by use of a \fIfcntl\fP call.
Third, it must turn on notification of pending i/o requests
with another \fIfcntl\fP call. Sample code to
allow a given process to receive information on
pending i/o requests as they occur for a socket \fIs\fP
is given in Figure 6. With slight change, this code can also
be used to prepare for receipt of SIGURG signals.
signal(SIGIO, io_handler);
/* Set the process receiving SIGIO/SIGURG signals to us */
if (fcntl(s, F_SETOWN, getpid()) < 0) {
perror("fcntl F_SETOWN");
/* Allow receipt of asynchronous i/o signals */
if (fcntl(s, F_SETFL, FASYNC) < 0) {
perror("fcntl F_SETFL, FASYNC");
Figure 6. Use of asynchronous notification of i/o requests.
Signals and process groups
Due to the existence of the SIGURG and SIGIO signals each socket has an
associated process number, just as is done for terminals.
This value is initialized to zero,
but may be redefined at a later time with the F_SETOWN
\fIfcntl\fP, such as was done in the code above for SIGIO.
To set the socket's process id for signals, positive arguments
should be given to the \fIfcntl\fP call. To set the socket's
process group for signals, negative arguments should be
passed to \fIfcntl\fP. Note that the process number indicates
either the associated process id or the associated process
group; it is impossible to specify both at the same time.
A similar \fIfcntl\fP, F_GETOWN, is available for determining the
current process number of a socket.
An old signal which is useful when constructing server processes
is SIGCHLD. This signal is delivered to a process when any
children processes have changed state. Normally servers use
the signal to \*(lqreap\*(rq child processes after exiting.
For example, the remote login server loop shown in Figure 2
may be augmented as shown in Figure 7.
int g, len = sizeof (from);
g = accept(f, (struct sockaddr *)&from, &len,);
syslog(LOG_ERR, "rlogind: accept: %m");
while (wait3(&status, WNOHANG, 0) > 0)
Figure 7. Use of the SIGCHLD signal.
If the parent server process fails to reap its children,
a large number of \*(lqzombie\*(rq processes may be created.
Many programs will not function properly without a terminal
for standard input and output. Since a socket is not a terminal,
it is often necessary to have a process communicating over
the network do so through a \fIpseudo terminal\fP. A pseudo
terminal is actually a pair of devices, master and slave,
which allow a process to serve as an active agent in communication
between processes and users. Data written on the slave side
of a pseudo terminal is supplied as input to a process reading
from the master side, while data written on the master side is
given to the slave as input. In this way, the process manipulating
the master side of the pseudo terminal has control over the
information read and written on the slave side.
The purpose of this abstraction is to
preserve terminal semantics over a network connection \(em
that is, the slave side looks like a normal terminal to
any process reading from or writing to it.
login server uses pseudo terminals for remote login sessions.
A user logging in to a machine across the network is provided
a shell with a slave pseudo terminal as standard input, output,
and error. The server process then handles the communication
between the programs invoked by the remote shell and the user's
local client process. When a user sends an interrupt or quit
signal to a process executing on a remote machine, the client
login program traps the signal, sends an out of band message
to the server process who then uses the signal number, sent
as the data value in the out of band message, to perform a
\fIkillpg\fP(2) on the appropriate process group.
Under 4.3BSD, the slave side of a pseudo terminal is
\fI/dev/ttyxy\fP, where \fIx\fP is a single letter
starting at `p' and perhaps continuing as far down
as `t'. \fIy\fP is a hexidecimal ``digit'' (i.e., a single
character in the range 0 through 9 or `a' through `f').
The master side of a pseudo terminal is \fI/dev/ptyxy\fP,
where \fIx\fP and \fIy\fP correspond to the same letters
in the slave side of the pseudo terminal.
In general, the method of obtaining a pair of master and
slave pseudo terminals is made up of three components.
First, the process must find a pseudo terminal which
is not currently in use. Having done so,
it then opens both the master and the slave side of
the device, taking care to open the master side of the device first.
The process then \fIfork\fPs; the child closes
the master side of the pseudo terminal, and \fIexec\fPs the
appropriate program. Meanwhile, the parent closes the
slave side of the pseudo terminal and begins reading and
writing from the master side. Sample code making use of
pseudo terminals is given in Figure 8; this code assumes
that a connection on a socket \fIs\fP exists, connected
to a peer who wants a service of some kind, and that the
process has disassociated itself from a controlling terminal.
for (c = 'p'; !gotpty && c <= 's'; c++) {
line[sizeof("/dev/pty")-1] = c;
line[sizeof("/dev/ptyp")-1] = '0';
if (stat(line, &statbuf) < 0)
for (i = 0; i < 16; i++) {
line[sizeof("/dev/ptyp")-1] = "0123456789abcdef"[i];
master = open(line, O_RDWR);
syslog(LOG_ERR, "All network ports in use");
line[sizeof("/dev/")-1] = 't';
slave = open(line, O_RDWR); /* \fIslave\fP is now slave side */
syslog(LOG_ERR, "Cannot open slave pty %s", line);
ioctl(slave, TIOCGETP, &b); /* Set slave tty modes */
b.sg_flags = CRMOD|XTABS|ANYP;
ioctl(slave, TIOCSETP, &b);
syslog(LOG_ERR, "fork: %m");
} else if (i) { /* Parent */
Figure 8. Creation and use of a pseudo terminal
Selecting specific protocols
If the third argument to the \fIsocket\fP call is 0,
\fIsocket\fP will select a default protocol to use with
the returned socket of the type requested. This
protocol should be correct for almost every situation.
Still, it is conceivable that the user may wish to specify
a particular protocol for use with a given socket.
To obtain a particular protocol one selects the protocol number,
as defined within the communication domain. For the Internet
domain the available protocols are defined in <\fInetinet/in.h\fP>
or, better yet, one may use one of the library routines
discussed in section 3, such as \fIgetprotobyname\fP:
pp = getprotobyname("newtcp");
s = socket(AF_INET, SOCK_STREAM, pp->p_proto);
This would result in a socket \fIs\fP using a stream
based connection, but with protocol type of ``newtcp''
instead of the default ``tcp.''
In the NS domain, the available socket protocols are defined in
<\fInetns/ns.h\fP>. To create a raw socket for Xerox Error Protocol
s = socket(AF_NS, SOCK_RAW, NSPROTO_ERROR);
As was mentioned in section 2,
binding addresses to sockets in the Internet and NS domains can be
fairly complex. As a brief reminder, these associations
are composed of local and foreign
addresses, and local and foreign ports. Port numbers are
allocated out of separate spaces, one for each system and one
for each domain on that system.
Through the \fIbind\fP system call, a
process may specify half of an association, the
<local address, local port> part, while the
primitives are used to complete a socket's association by
specifying the <foreign address, foreign port> part.
Since the association is created in two steps the association
uniqueness requirement indicated previously could be violated unless
care is taken. Further, it is unrealistic to expect user
programs to always know proper values to use for the local address
and local port since a host may reside on multiple networks and
the set of allocated port numbers is not directly accessible
To simplify local address binding in the Internet domain the notion of a
\*(lqwildcard\*(rq address has been provided. When an address
is specified as INADDR_ANY (a manifest constant defined in
<netinet/in.h>), the system interprets the address as
\*(lqany valid address\*(rq. For example, to bind a specific
port number to a socket, but leave the local address unspecified,
the following code might be used:
s = socket(AF_INET, SOCK_STREAM, 0);
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(MYPORT);
bind(s, (struct sockaddr *) &sin, sizeof (sin));
Sockets with wildcarded local addresses may receive messages
directed to the specified port number, and addressed to any
of the possible addresses assigned to a host. For example,
if a host is on a networks 128.32 and 10 and a socket is bound as
above, then an accept call is performed, the process will be
able to accept connection requests which arrive either from
network 128.32 or network 10.
If a server process wished to only allow hosts on a
given network connect to it, it would bind
the address of the host on the appropriate network. Such
an address could perhaps be determined by a routine
such as \fIgethostbynameandnet\fP, as mentioned in section 3.
In a similar fashion, a local port may be left unspecified
(specified as zero), in which case the system will select an
appropriate port number for it. This shortcut will work
both in the Internet and NS domains. For example, to
bind a specific local address to a socket, but to leave the
local port number unspecified:
hp = gethostbyname(hostname);
bcopy(hp->h_addr, (char *) sin.sin_addr, hp->h_length);
bind(s, (struct sockaddr *) &sin, sizeof (sin));
The system selects the local port number based on two criteria.
The first is that on 4BSD systems,
local ports numbered 0 through 1023 (for the Xerox domain,
0 through 3000) are reserved
for privileged users (i.e., the super user). The second is
that the port number is not currently bound to some other
socket. In order to find a free Internet port number in the privileged
range the \fIrresvport\fP library routine may be used as follows
to return a stream socket in with a privileged port number:
int lport = IPPORT_RESERVED \- 1;
fprintf(stderr, "socket: all ports in use\en");
perror("rresvport: socket");
The restriction on allocating ports was done to allow processes
executing in a \*(lqsecure\*(rq environment to perform authentication
based on the originating address and port number. For example,
the \fIrlogin\fP(1) command allows users to log in across a network
without being asked for a password, if two conditions hold:
First, the name of the system the user
is logging in from is in the file
\fI/etc/hosts.equiv\fP on the system he is logging
in to (or the system name and the user name are in
the user's \fI.rhosts\fP file in the user's home
directory), and second, that the user's rlogin
process is coming from a privileged port on the machine he is
logging in from. The port number and network address of the
machine the user is logging in from can be determined either
by the \fIfrom\fP value-result parameter to the \fIaccept\fP call, or
from the \fIgetpeername\fP call.
In certain cases the algorithm used by the system in selecting
port numbers is unsuitable for an application. This is due to
associations being created in a two step process. For example,
the Internet file transfer protocol, FTP, specifies that data
connections must always originate from the same local port. However,
duplicate associations are avoided by connecting to different foreign
ports. In this situation the system would disallow binding the
same local address and port number to a socket if a previous data
connection's socket were around. To override the default port
selection algorithm then an option call must be performed prior
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
bind(s, (struct sockaddr *) &sin, sizeof (sin));
With the above call, local addresses may be bound which
are already in use. This does not violate the uniqueness
requirement as the system still checks at connect time to
be sure any other sockets with the same local address and
port do not have the same foreign address and port (if an
association already exists, the error EADDRINUSE is returned).
Broadcasting and datagram sockets
By using a datagram socket it is possible to send broadcast
packets on many networks supported by the system (the network
itself must support the notion of broadcasting; the system
provides no broadcast simulation in software). Broadcast
messages can place a high load on a network since they force
every host on the network to service them. Consequently,
the ability to send broadcast packets has been limited
to sockets which are explicitly marked as allowing broadcasting.
To send a broadcast message, a datagram socket
s = socket(AF_INET, SOCK_DGRAM, 0);
s = socket(AF_NS, SOCK_DGRAM, 0);
The socket is marked as allowing broadcasting,
setsockopt(s, SOL_SOCKET, SO_BROADCAST, &on, sizeof (on));
and at least a port number should be bound to the socket:
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(MYPORT);
bind(s, (struct sockaddr *) &sin, sizeof (sin));
sns.sns_addr.x_net = *(union ns_net *) &netnum; /* insert net number */
sns.sns_addr.x_port = htons(MYPORT);
bind(s, (struct sockaddr *) &sns, sizeof (sns));
The destination address of the message to be broadcast
depends on the network the message is to be broadcast
on, and therefore requires some knowledge of the networks
to which the host is connected. Since this information should
be obtained in a host-independent fashion, 4.3BSD provides a method of
retrieving this information from the system data structures.
The SIOCGIFCONF \fIioctl\fP call returns the interface
configuration of a host in the form of a
single \fIifconf\fP structure; this structure contains
a ``data area'' which is made up of an array of
of \fIifreq\fP structures, one for each network interface
to which the host is connected.
These structures are defined in
\fI<net/if.h>\fP as follows:
.if t .ta .5i 1.0i 1.5i 3.5i
.if n .ta .7i 1.4i 2.1i 3.4i
int ifc_len; /* size of associated buffer */
#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
.if t .ta \w' #define'u +\w' ifr_broadaddr'u +\w' ifr_ifru.ifru_broadaddr'u
#define ifr_addr ifr_ifru.ifru_addr /* address */
#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
#define ifr_flags ifr_ifru.ifru_flags /* flags */
#define ifr_data ifr_ifru.ifru_data /* for use by interface */
The actual call which obtains the
interface configuration is
ifc.ifc_len = sizeof (buf);
if (ioctl(s, SIOCGIFCONF, (char *) &ifc) < 0) {
After this call \fIbuf\fP will contain one \fIifreq\fP structure for
each network to which the host is connected, and
\fIifc.ifc_len\fP will have been modified to reflect the number
of bytes used by the \fIifreq\fP structures.
there exists a set of ``interface flags'' which tell
whether the network corresponding to that interface is
up or down, point to point or broadcast, etc. The
SIOCGIFFLAGS \fIioctl\fP retrieves these
flags for an interface specified by an \fIifreq\fP
for (n = ifc.ifc_len / sizeof (struct ifreq); --n >= 0; ifr++) {
* We must be careful that we don't use an interface
* devoted to an address family other than our own;
* if we were interested in NS interfaces, the
* AF_INET would be AF_NS.
if (ifr->ifr_addr.sa_family != AF_INET)
if (ioctl(s, SIOCGIFFLAGS, (char *) ifr) < 0) {
if ((ifr->ifr_flags & IFF_UP) == 0 || /* Skip boring cases */
(ifr->ifr_flags & (IFF_BROADCAST | IFF_POINTTOPOINT)) == 0)
Once the flags have been obtained, the broadcast address
must be obtained. In the case of broadcast networks this is
done via the SIOCGIFBRDADDR \fIioctl\fP, while for point-to-point networks
the address of the destination host is obtained with SIOCGIFDSTADDR.
if (ifr->ifr_flags & IFF_POINTTOPOINT) {
if (ioctl(s, SIOCGIFDSTADDR, (char *) ifr) < 0) {
bcopy((char *) ifr->ifr_dstaddr, (char *) &dst, sizeof (ifr->ifr_dstaddr));
} else if (ifr->ifr_flags & IFF_BROADCAST) {
if (ioctl(s, SIOCGIFBRDADDR, (char *) ifr) < 0) {
bcopy((char *) ifr->ifr_broadaddr, (char *) &dst, sizeof (ifr->ifr_broadaddr));
After the appropriate \fIioctl\fP's have obtained the broadcast
or destination address (now in \fIdst\fP), the \fIsendto\fP call may be
sendto(s, buf, buflen, 0, (struct sockaddr *)&dst, sizeof (dst));
In the above loop one \fIsendto\fP occurs for every
interface the host is connected to which supports the notion of
broadcast or point-to-point addressing.
If a process only wished to send broadcast
messages on a given network, code similar to that outlined above
would be used, but the loop would need to find the
correct destination address.
Received broadcast messages contain the senders address
and port, as datagram sockets are bound before
a message is allowed to go out.
It is possible to set and get a number of options on sockets
via the \fIsetsockopt\fP and \fIgetsockopt\fP system calls.
These options include such things as marking a socket for
broadcasting, not to route, to linger on close, etc.
The general forms of the calls are:
setsockopt(s, level, optname, optval, optlen);
getsockopt(s, level, optname, optval, optlen);
The parameters to the calls are as follows: \fIs\fP
is the socket on which the option is to be applied.
\fILevel\fP specifies the protocol layer on which the
option is to be applied; in most cases this is
the ``socket level'', indicated by the symbolic constant
SOL_SOCKET, defined in \fI<sys/socket.h>.\fP
The actual option is specified in \fIoptname\fP, and is
a symbolic constant also defined in \fI<sys/socket.h>\fP.
\fIOptval\fP and \fIOptlen\fP point to the value of the
option (in most cases, whether the option is to be turned
on or off), and the length of the value of the option,
For \fIgetsockopt\fP, \fIoptlen\fP is
a value-result parameter, initially set to the size of
the storage area pointed to by \fIoptval\fP, and modified
upon return to indicate the actual amount of storage used.
An example should help clarify things. It is sometimes
useful to determine the type (e.g., stream, datagram, etc.)
of an existing socket; programs
under \fIinetd\fP (described below) may need to perform this
task. This can be accomplished as follows via the
SO_TYPE socket option and the \fIgetsockopt\fP call:
if (getsockopt(s, SOL_SOCKET, SO_TYPE, (char *) &type, &size) < 0) {
After the \fIgetsockopt\fP call, \fItype\fP will be set
to the value of the socket type, as defined in
\fI<sys/socket.h>\fP. If, for example, the socket were
a datagram socket, \fItype\fP would have the value
corresponding to SOCK_DGRAM.
The semantics of NS connections demand that
the user both be able to look inside the network header associated
with any incoming packet and be able to specify what should go
in certain fields of an outgoing packet. The header of an
IDP-level packet looks like:
.if t .ta \w'struct 'u +\w" struct ns_addr"u +2.0i
u_short idp_sum; /* Checksum */
u_short idp_len; /* Length, in bytes, including header */
u_char idp_tc; /* Transport Control (i.e., hop count) */
u_char idp_pt; /* Packet Type (i.e., level 2 protocol) */
struct ns_addr idp_dna; /* Destination Network Address */
struct ns_addr idp_sna; /* Source Network Address */
Most of the fields are filled in automatically; the only
field that the user should be concerned with is the
\fIpacket type\fP field. The standard values for this
field are (as defined in <\fInetns/ns.h\fP>):
.if t .ta \w" #define"u +\w" NSPROTO_ERROR"u +1.0i
#define NSPROTO_RI 1 /* Routing Information */
#define NSPROTO_ECHO 2 /* Echo Protocol */
#define NSPROTO_ERROR 3 /* Error Protocol */
#define NSPROTO_PE 4 /* Packet Exchange */
#define NSPROTO_SPP 5 /* Sequenced Packet */
For SPP connections, the contents of this field are
automatically set to NSPROTO_SPP; for IDP packets,
this value defaults to zero, which means ``unknown''.
The contents of a SPP header (minus the IDP header) are:
.if t .ta \w" #define"u +\w" u_short"u +2.0i
u_char sp_cc; /* connection control */
#define SP_SP 0x80 /* system packet */
#define SP_SA 0x40 /* send acknowledgement */
#define SP_OB 0x20 /* attention (out of band data) */
#define SP_EM 0x10 /* end of message */
u_char sp_dt; /* datastream type */
u_short sp_sid; /* source connection identifier */
u_short sp_did; /* destination connection identifier */
u_short sp_seq; /* sequence number */
u_short sp_ack; /* acknowledge number */
u_short sp_alo; /* allocation number */
Here, the items of interest are the \fIdatastream type\fP and
the \fIconnection control\fP fields. The semantics of the
datastream type are defined by the application(s) in question;
the value of this field is, by default, zero, but it can be
used to indicate things such as Xerox's Bulk Data Transfer
Protocol (in which case it is set to one). The connection control
field is a mask of the flags defined above. The user may
set or clear the end-of-message bit to indicate
that a given message is the last of a given substream type,
or may set/clear the attention bit as an alternate way to
indicate that a packet should be sent out-of-band.
Using different calls to \fIsetsockopt\fP, is it possible
to indicate whether prototype headers will be associated by
the user with each outgoing packet (SO_HEADERS_ON_OUTPUT),
to indicate whether the headers received by the system should be
delivered to the user (SO_HEADERS_ON_INPUT), or to indicate
default information that should be associated with all
outgoing packets on a given socket (SO_DEFAULT_HEADERS).
For example, to associate prototype headers with outgoing
SPP packets, one might use:
struct sockaddr_ns sns, to;
struct sphdr proto_spp; /* prototype header */
char buf[534]; /* max. possible data by Xerox std. */
s = socket(AF_NS, SOCK_SEQPACKET, 0);
bind(s, (struct sockaddr *) &sns, sizeof (sns));
setsockopt(s, NSPROTO_SPP, SO_HEADERS_ON_OUTPUT, &on, sizeof(on));
buf.proto_spp.sp_dt = 1; /* bulk data */
buf.proto_spp.sp_cc = SP_EM; /* end-of-message */
strcpy(buf.buf, "hello world\en");
sendto(s, (char *) &buf, sizeof(struct sphdr) + strlen("hello world\en"),
(struct sockaddr *) &to, sizeof(to));
Note that one must be careful when writing headers; if the prototype
header is not written with the data with which it is to be associated,
the kernel will treat the first few bytes of the data as the
header, with unpredictable results.
To turn off the above association, and to indicate that packet
headers received by the system should be passed up to the user,
s = socket(AF_NS, SOCK_SEQPACKET, 0);
bind(s, (struct sockaddr *) &sns, sizeof (sns));
setsockopt(s, NSPROTO_SPP, SO_HEADERS_ON_OUTPUT, &off, sizeof(off));
setsockopt(s, NSPROTO_SPP, SO_HEADERS_ON_INPUT, &on, sizeof(on));
To indicate a default prototype header to be associated with
the outgoing packets on an IDP datagram socket, one would use:
struct idp proto_idp; /* prototype header */
s = socket(AF_NS, SOCK_DGRAM, 0);
bind(s, (struct sockaddr *) &sns, sizeof (sns));
proto_idp.idp_pt = NSPROTO_PE; /* packet exchange */
setsockopt(s, NSPROTO_IDP, SO_DEFAULT_HEADERS, (char *) &proto_idp,
The semantics of SPP connections indicates that a three-way
handshake, involving changes in the datastream type, should \(em
but is not absolutely required to \(em take place before a SPP
connection is closed. Almost all SPP connections are
``well-behaved'' in this manner; when communicating with
any process, it is best to assume that the three-way handshake
is required unless it is known for certain that it is not
required. In a three-way close, the closing process
indicates that it wishes to close the connection by sending
a zero-length packet with end-of-message set and with
datastream type 254. The other side of the connection
indicates that it is OK to close by sending a zero-length
packet with end-of-message set and datastream type 255. Finally,
the closing process replies with a zero-length packet with
substream type 255; at this point, the connection is considered
closed. The following code fragments are simplified examples
of how one might handle this three-way handshake at the user
level; in the future, support for this type of close will
probably be provided as part of the C library or as part of
the kernel. The first code fragment below illustrates how a process
might handle three-way handshake if it sees that the process it
is communicating with wants to close the connection:
#define SPPSST_ENDREPLY 255
if (((struct sphdr *)buf)->sp_dt == SPPSST_END) {
* SPPSST_END indicates that the other side wants to
proto_sp.sp_dt = SPPSST_ENDREPLY;
setsockopt(s, NSPROTO_SPP, SO_DEFAULT_HEADERS, (char *)&proto_sp,
* Write a zero-length packet with datastream type = SPPSST_ENDREPLY
* to indicate that the close is OK with us. The packet that we
* don't see (because we don't look for it) is another packet
* from the other side of the connection, with SPPSST_ENDREPLY
* on it it, too. Once that packet is sent, the connection is
* considered closed; note that we really ought to retransmit
* the close for some time if we do not get a reply.
To indicate to another process that we would like to close the
connection, the following code would suffice:
#define SPPSST_ENDREPLY 255
proto_sp.sp_dt = SPPSST_END;
setsockopt(s, NSPROTO_SPP, SO_DEFAULT_HEADERS, (char *)&proto_sp,
write(s, buf, 0); /* send the end request */
proto_sp.sp_dt = SPPSST_ENDREPLY;
setsockopt(s, NSPROTO_SPP, SO_DEFAULT_HEADERS, (char *)&proto_sp,
* We assume (perhaps unwisely)
* that the other side will send the
* ENDREPLY, so we'll just send our final ENDREPLY
* as if we'd seen theirs already.
The Xerox standard protocols include a protocol that is both
reliable and datagram-oriented. This protocol is known as
Packet Exchange (PEX or PE) and, like SPP, is layered on top
of IDP. PEX is important for a number of things: Courier
remote procedure calls may be expedited through the use
of PEX, and many Xerox servers are located by doing a PEX
``BroadcastForServers'' operation. Although there is no
implementation of PEX in the kernel,
it may be simulated at the user level with some clever coding
and the use of one peculiar \fIgetsockopt\fP. A PEX packet
.if t .ta \w'struct 'u +\w" struct idp"u +2.0i
* The packet-exchange header shown here is not defined
* as part of any of the system include files.
struct idp p_idp; /* idp header */
u_short ph_id[2]; /* unique transaction ID for pex */
u_short ph_client; /* client type field for pex */
The \fIph_id\fP field is used to hold a ``unique id'' that
is used in duplicate suppression; the \fIph_client\fP
field indicates the PEX client type (similar to the packet
type field in the IDP header). PEX reliability stems from the
fact that it is an idempotent (``I send a packet to you, you
send a packet to me'') protocol. Processes on each side of
the connection may use the unique id to determine if they have
seen a given packet before (the unique id field differs on each
packet sent) so that duplicates may be detected, and to indicate
which message a given packet is in response to. If a packet with
a given unique id is sent and no response is received in a given
amount of time, the packet is retransmitted until it is decided
that no response will ever be received. To simulate PEX, one
must be able to generate unique ids -- something that is hard to
do at the user level with any real guarantee that the id is really
unique. Therefore, a means (via \fIgetsockopt\fP) has been provided
for getting unique ids from the kernel. The following code fragment
indicates how to get a unique id:
int s, idsize = sizeof(uniqueid);
s = socket(AF_NS, SOCK_DGRAM, 0);
/* get id from the kernel -- only on IDP sockets */
getsockopt(s, NSPROTO_PE, SO_SEQNO, (char *)&uniqueid, &idsize);
The retransmission and duplicate suppression code required to
simulate PEX fully is left as an exercise for the reader.
It is occasionally convenient to make use of sockets
which do not block; that is, i/o requests which
would cause the process to wait for their completion are
not executed, and an error code is returned.
Once a socket has been created via
the \fIsocket\fP call, it may be marked as non-blocking
by \fIfcntl\fP as follows:
s = socket(AF_INET, SOCK_STREAM, 0);
if (fcntl(s, F_SETFL, FNDELAY) < 0)
perror("fcntl F_SETFL, FNDELAY");
When performing non-blocking i/o on sockets, one must be
careful to check for the error EWOULDBLOCK (stored in the
global variable \fIerrno\fP), which occurs when
an operation would normally block, but the socket it
was performed on is marked as non-blocking.
In particular, \fIaccept\fP, \fIconnect\fP, \fIsend\fP, \fIrecv\fP,
\fIread\fP, and \fIwrite\fP can
all return EWOULDBLOCK, and processes should be prepared
to deal with such return codes.
One of the daemons provided with 4.3BSD is \fIinetd\fP, the
so called ``internet super-server.'' \fIInetd\fP is invoked at boot
time, and determines from the file \fI/etc/inetd.conf\fP the
servers for which it is to listen. Once this information has been
read and a pristine environment created, \fIinetd\fP proceeds
to create one socket for each service it is to listen for,
binding the appropriate port number to each socket.
\fIInetd\fP then performs a \fIselect\fP on all these
sockets for read availability, waiting for somebody wishing
a connection to the service corresponding to
that socket. \fIInetd\fP then performs an \fIaccept\fP on
the socket in question, \fIfork\fPs, \fIdup\fPs the new
socket to file descriptors 0 and 1 (stdin and
stdout), closes other open file
descriptors, and \fIexec\fPs the appropriate server.
Servers making use of \fIinetd\fP are considerably simplified,
as \fIinetd\fP takes care of the majority of the IPC work
required in establishing a connection. The server invoked
by \fIinetd\fP expects the socket connected to its client
on file descriptors 0 and 1, and may immediately perform
any operations such as \fIread\fP, \fIwrite\fP, \fIsend\fP,
or \fIrecv\fP. Indeed, servers may use
buffered i/o as provided by the ``stdio'' conventions, as
long as as they remember to use \fIfflush\fP when appropriate.
One call which may be of interest to individuals writing
servers under \fIinetd\fP is the \fIgetpeername\fP call,
which returns the address of the peer (process) connected
on the other end of the socket. For example, to log the
Internet address in ``dot notation'' (e.g., ``128.32.0.4'')
of a client connected to a server under
\fIinetd\fP, the following code might be used:
int namelen = sizeof (name);
if (getpeername(0, (struct sockaddr *)&name, &namelen) < 0) {
syslog(LOG_ERR, "getpeername: %m");
syslog(LOG_INFO, "Connection from %s", inet_ntoa(name.sin_addr));
While the \fIgetpeername\fP call is especially useful when
writing programs to run with \fIinetd\fP, it can be used
at any time. Be warned, however, that \fIgetpeername\fP will
fail on UNIX domain sockets, as their addresses (i.e., pathnames)
projects / unix-history / blob