SCCS-vsn: share/doc/psd/21.ipc/0.t 5.2
SCCS-vsn: share/doc/psd/21.ipc/1.t 5.2
SCCS-vsn: share/doc/psd/21.ipc/2.t 5.2
SCCS-vsn: share/doc/psd/21.ipc/3.t 5.2
SCCS-vsn: share/doc/psd/21.ipc/4.t 5.2
-.\" Copyright (c) 1986 The Regents of the University of California.
+.\" Copyright (c) 1986, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
-.\" @(#)0.t 5.1 (Berkeley) %G%
+.\" @(#)0.t 5.2 (Berkeley) %G%
-.EH 'PS1:8-%''Advanced 4.3BSD IPC Tutorial'
-.OH 'Advanced 4.3BSD IPC Tutorial''PS1:8-%'
+.EH 'PS1:8-%''Advanced 4.4BSD IPC Tutorial'
+.OH 'Advanced 4.4BSD IPC Tutorial''PS1:8-%'
.ds lq ``
.ds rq ''
.de DT
.ds lq ``
.ds rq ''
.de DT
-An Advanced 4.3BSD Interprocess Communication Tutorial
+An Advanced 4.4BSD Interprocess Communication Tutorial
.AU
Samuel J. Leffler
.AU
.AU
Samuel J. Leffler
.AU
-* \s-2UNIX\s0 is a Trademark of Bell Laboratories.
+* \s-2UNIX\s0 is a trademark of UNIX System Laboratories, Inc.
+in the US and some other countries.
.FE
This document provides an introduction to the interprocess
communication facilities included in the
.FE
This document provides an introduction to the interprocess
communication facilities included in the
-.\" Copyright (c) 1986 The Regents of the University of California.
+.\" Copyright (c) 1986, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
-.\" @(#)1.t 5.1 (Berkeley) %G%
+.\" @(#)1.t 5.2 (Berkeley) %G%
-.\".ds LH "4.3BSD IPC Primer
+.\".ds LH "4.4BSD IPC Primer
.\".ds RH Introduction
.\".ds RF "Leffler/Fabry/Joy
.\".ds LF "\*(DY
.\".ds RH Introduction
.\".ds RF "Leffler/Fabry/Joy
.\".ds LF "\*(DY
provided in 4.2BSD incorporated many of the ideas from current
research, while trying to maintain the UNIX philosophy of
simplicity and conciseness.
provided in 4.2BSD incorporated many of the ideas from current
research, while trying to maintain the UNIX philosophy of
simplicity and conciseness.
-The current release of Berkeley UNIX, 4.3BSD,
-completes some of the IPC facilities
-and provides an upward-compatible interface.
-It is hoped that the interprocess communication
-facilities included in 4.3BSD will establish a
-standard for UNIX. From the response to the design,
-it appears many organizations carrying out
-work with UNIX are adopting it.
+The 4.3BSD release of Berkeley UNIX
+improved upon some of the IPC facilities
+while providing an upward-compatible interface.
+4.4BSD adds support for ISO protocols and IP multicasting.
+The BSD interprocess communication
+facilities have become a defacto standard for UNIX.
.PP
UNIX has previously been very weak in the area of interprocess
communication. Prior to the 4BSD facilities, the only
.PP
UNIX has previously been very weak in the area of interprocess
communication. Prior to the 4BSD facilities, the only
met with mixed reaction. The majority of the problems have
been related to the fact that these facilities have been tied to
the UNIX file system, either through naming or implementation.
met with mixed reaction. The majority of the problems have
been related to the fact that these facilities have been tied to
the UNIX file system, either through naming or implementation.
-Consequently, the IPC facilities provided in 4.3BSD have been
-designed as a totally independent subsystem. The 4.3BSD IPC
+Consequently, the IPC facilities provided in 4.2BSD were
+designed as a totally independent subsystem. The BSD IPC
allows processes to rendezvous in many ways.
Processes may rendezvous through a UNIX file system-like
name space (a space where all names are path names)
allows processes to rendezvous in many ways.
Processes may rendezvous through a UNIX file system-like
name space (a space where all names are path names)
only time will tell.
.PP
This document provides a high-level description
only time will tell.
.PP
This document provides a high-level description
-of the IPC facilities in 4.3BSD and their use.
+of the IPC facilities in 4.4BSD and their use.
It is designed to complement the manual pages for the IPC primitives
by examples of their use.
The remainder of this document is organized in four sections.
It is designed to complement the manual pages for the IPC primitives
by examples of their use.
The remainder of this document is organized in four sections.
-.\" Copyright (c) 1986 The Regents of the University of California.
+.\" Copyright (c) 1986, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
-.\" @(#)2.t 5.1 (Berkeley) %G%
+.\" @(#)2.t 5.2 (Berkeley) %G%
.\"
.\".ds RH "Basics
.bp
.\"
.\".ds RH "Basics
.bp
sockets in the same domain (it may be possible to cross domain
boundaries, but only if some translation process is
performed). The
sockets in the same domain (it may be possible to cross domain
boundaries, but only if some translation process is
performed). The
-4.3BSD IPC facilities support three separate communication domains:
+4.4BSD IPC facilities support four separate communication domains:
the UNIX domain, for on-system communication;
the Internet domain, which is used by
processes which communicate
the UNIX domain, for on-system communication;
the Internet domain, which is used by
processes which communicate
-using the the DARPA standard communication protocols;
-and the NS domain, which is used by processes which
+using the Internet standard communication protocols;
+the NS domain, which is used by processes which
communicate using the Xerox standard communication
communicate using the Xerox standard communication
.FS
* See \fIInternet Transport Protocols\fP, Xerox System Integration
Standard (XSIS)028112 for more information. This document is
almost a necessity for one trying to write NS applications.
.FE
.FS
* See \fIInternet Transport Protocols\fP, Xerox System Integration
Standard (XSIS)028112 for more information. This document is
almost a necessity for one trying to write NS applications.
.FE
+and the ISO OSI protocols, which are not documented in this tutorial.
The underlying communication
facilities provided by these domains have a significant influence
on the internal system implementation as well as the interface to
The underlying communication
facilities provided by these domains have a significant influence
on the internal system implementation as well as the interface to
strcpy(addr.sun_path, "/tmp/foo");
addr.sun_family = AF_UNIX;
bind(s, (struct sockaddr *) &addr, strlen(addr.sun_path) +
strcpy(addr.sun_path, "/tmp/foo");
addr.sun_family = AF_UNIX;
bind(s, (struct sockaddr *) &addr, strlen(addr.sun_path) +
- sizeof (addr.sun_family));
+ sizeof (addr.sun_len) + sizeof (addr.sun_family));
.DE
Note that in determining the size of a UNIX domain address null
bytes are not counted, which is why \fIstrlen\fP is used. In
.DE
Note that in determining the size of a UNIX domain address null
bytes are not counted, which is why \fIstrlen\fP is used. In
-the current implementation of UNIX domain IPC under 4.3BSD,
+the current implementation of UNIX domain IPC,
the file name
referred to in \fIaddr.sun_path\fP is created as a socket
in the system file space.
the file name
referred to in \fIaddr.sun_path\fP is created as a socket
in the system file space.
-.\" Copyright (c) 1986 The Regents of the University of California.
+.\" Copyright (c) 1986, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
-.\" @(#)3.t 5.1 (Berkeley) %G%
+.\" @(#)3.t 5.2 (Berkeley) %G%
.\"
.\".ds RH "Network Library Routines
.bp
.\"
.\".ds RH "Network Library Routines
.bp
environment. To aid in this task a number of routines
have been added to the standard C run-time library.
In this section we will consider the new routines provided
environment. To aid in this task a number of routines
have been added to the standard C run-time library.
In this section we will consider the new routines provided
-to manipulate network addresses. While the 4.3BSD networking
-facilities support both the DARPA standard Internet protocols
-and the Xerox NS protocols, most of the routines presented
+to manipulate network addresses. While the 4.4BSD networking
+facilities support the Internet protocols
+and the Xerox NS protocols,
+most of the routines presented
in this section do not apply to the NS domain. Unless otherwise
stated, it should be assumed that the routines presented in this
section do not apply to the NS domain.
in this section do not apply to the NS domain. Unless otherwise
stated, it should be assumed that the routines presented in this
section do not apply to the NS domain.
.KE
.PP
The byte swapping routines are provided because the operating
.KE
.PP
The byte swapping routines are provided because the operating
-system expects addresses to be supplied in network order. On
-some architectures, such as the VAX,
+system expects addresses to be supplied in network order (aka ``big-endian'' order). On
+``little-endian'' architectures, such as Intel x86 and VAX,
host byte ordering is different than
network byte ordering. Consequently,
programs are sometimes required to byte swap quantities. The
host byte ordering is different than
network byte ordering. Consequently,
programs are sometimes required to byte swap quantities. The
-.\" Copyright (c) 1986 The Regents of the University of California.
+.\" Copyright (c) 1986, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
.\" All rights reserved.
.\"
.\" %sccs.include.redist.roff%
.\"
-.\" @(#)4.t 5.1 (Berkeley) %G%
+.\" @(#)4.t 5.2 (Berkeley) %G%
.\"
.\".ds RH "Client/Server Model
.bp
.\"
.\".ds RH "Client/Server Model
.bp
Alternative schemes which use a service server
may be used to eliminate a flock of server processes clogging the
system while remaining dormant most of the time. For Internet
Alternative schemes which use a service server
may be used to eliminate a flock of server processes clogging the
system while remaining dormant most of the time. For Internet
this scheme has been implemented via \fIinetd\fP, the so called
``internet super-server.'' \fIInetd\fP listens at a variety
of ports, determined at start-up by reading a configuration file.
this scheme has been implemented via \fIinetd\fP, the so called
``internet super-server.'' \fIInetd\fP listens at a variety
of ports, determined at start-up by reading a configuration file.
-In 4.3BSD most servers are accessed at well known Internet addresses
+In 4.4BSD most servers are accessed at well known Internet addresses
or UNIX domain names. For
example, the remote login server's main loop is of the form shown
in Figure 2.
or UNIX domain names. For
example, the remote login server's main loop is of the form shown
in Figure 2.
Unless such a service is sufficiently universal and is frequently used,
the expense of periodic broadcasts outweighs the simplicity.
.PP
Unless such a service is sufficiently universal and is frequently used,
the expense of periodic broadcasts outweighs the simplicity.
.PP
+Multicasting is an alternative to broadcasting.
+Setting up multicast sockets is described in Section 5.10.
+.PP
The rwho server, in a simplified form, is pictured in Figure
4. There are two separate tasks performed by the server. The
first task is to act as a receiver of status information broadcast
The rwho server, in a simplified form, is pictured in Figure
4. There are two separate tasks performed by the server. The
first task is to act as a receiver of status information broadcast
It is important that software operating in a distributed
environment not have any site-dependent information compiled into it.
This would require a separate copy of the server at each host and
It is important that software operating in a distributed
environment not have any site-dependent information compiled into it.
This would require a separate copy of the server at each host and
-make maintenance a severe headache. 4.3BSD attempts to isolate
+make maintenance a severe headache. 4.4BSD attempts to isolate
host-specific information from applications by providing system
calls which return the necessary information*.
.FS
host-specific information from applications by providing system
calls which return the necessary information*.
.FS
Combining these two features allows a process
to broadcast on any directly connected local
network which supports the notion of broadcasting
Combining these two features allows a process
to broadcast on any directly connected local
network which supports the notion of broadcasting
-in a site independent manner. This allows 4.3BSD
+in a site independent manner. This allows 4.4BSD
to solve the problem of deciding how to propagate
status information in the case of \fIrwho\fP, or
more generally in broadcasting:
to solve the problem of deciding how to propagate
status information in the case of \fIrwho\fP, or
more generally in broadcasting: