4.4 updates
authorAndrew Cherenson <andrew@ucbvax.Berkeley.EDU>
Sat, 15 May 1993 08:51:52 +0000 (00:51 -0800)
committerAndrew Cherenson <andrew@ucbvax.Berkeley.EDU>
Sat, 15 May 1993 08:51:52 +0000 (00:51 -0800)
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

usr/src/share/doc/psd/21.ipc/0.t
usr/src/share/doc/psd/21.ipc/1.t
usr/src/share/doc/psd/21.ipc/2.t
usr/src/share/doc/psd/21.ipc/3.t
usr/src/share/doc/psd/21.ipc/4.t

index 7b79a7e..f484ebe 100644 (file)
@@ -1,12 +1,12 @@
-.\" 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
@@ -16,7 +16,7 @@
 ..
 .bd S B 3
 .TL
 ..
 .bd S B 3
 .TL
-An Advanced 4.3BSD Interprocess Communication Tutorial
+An Advanced 4.4BSD Interprocess Communication Tutorial
 .AU
 Samuel J. Leffler
 .AU
 .AU
 Samuel J. Leffler
 .AU
@@ -49,11 +49,12 @@ UNIX\\$1
 .AB
 .PP
 .FS
 .AB
 .PP
 .FS
-* \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
-4.3BSD release of the
+4.4BSD release of the
 .UX *
 system.
 .PP
 .UX *
 system.
 .PP
index 5f1d0ba..df301f7 100644 (file)
@@ -1,11 +1,11 @@
-.\" 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
@@ -27,14 +27,12 @@ more than two years of discussion and research.  The facilities
 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
@@ -51,8 +49,8 @@ Earlier attempts at extending the IPC facilities of UNIX have
 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)
@@ -68,7 +66,7 @@ more use is made of these facilities they will be refined;
 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.  
index a290b5a..2852dea 100644 (file)
@@ -1,9 +1,9 @@
-.\" 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
@@ -34,19 +34,20 @@ exchange data only with
 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
-protocols*.
+protocols*;
 .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
@@ -239,11 +240,11 @@ struct sockaddr_un addr;
 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.
index f46d400..a0fb68c 100644 (file)
@@ -1,9 +1,9 @@
-.\" 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
@@ -24,9 +24,10 @@ interprocess communication facilities in a distributed
 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.
@@ -315,8 +316,8 @@ Table 1.  C run-time routines.
 .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
index 37e9cac..a00886a 100644 (file)
@@ -1,9 +1,9 @@
-.\" 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
@@ -53,7 +53,7 @@ performing whatever appropriate actions the client requests of it.
 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
-servers in 4.3BSD,
+servers in 4.4BSD,
 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.
@@ -78,7 +78,7 @@ to NS clients and services that do not use Courier.
 .NH 2
 Servers
 .PP
 .NH 2
 Servers
 .PP
-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.
@@ -342,6 +342,9 @@ as all hosts must process each message, whether or not using an rwho server.
 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
@@ -457,7 +460,7 @@ to an endless, wasteful, exchange of information.
 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
@@ -472,7 +475,7 @@ has been implemented at the socket level.
 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: