4.4BSD snapshot (revision 8.1); add 1993 to copyright

[unix-history] / usr / src / share / doc / psd / 20.ipctut / tutor.me

diff --git a/usr/src/share/doc/psd/20.ipctut/tutor.me b/usr/src/share/doc/psd/20.ipctut/tutor.me
index 8ae3966..3d75ddd 100644 (file)
--- a/usr/src/share/doc/psd/20.ipctut/tutor.me
+++ b/usr/src/share/doc/psd/20.ipctut/tutor.me
@@ -1,17 +1,18 @@
-.\" Copyright (c) 1980 Regents of the University of California.
-.\" All rights reserved.  The Berkeley software License Agreement
-.\" specifies the terms and conditions for redistribution.
+.\" Copyright (c) 1986 The Regents of the University of California.
+.\" All rights reserved.

 .\"
 .\"

-.\"    @(#)tutor.me    6.3 (Berkeley) %G%
+.\" %sccs.include.redist.roff%

 .\"
 .\"

-.oh 'Introductory 4.3BSD IPC''PS1:7-%'
-.eh 'PS1:7-%''Introductory 4.3BSD IPC'
+.\"    @(#)tutor.me    8.1 (Berkeley) %G%
+.\"
+.oh 'Introductory 4.4BSD IPC''PSD:20-%'
+.eh 'PSD:20-%''Introductory 4.4BSD IPC'

 .rs
 .sp 2
 .sz 14
 .ft B
 .ce 2
 .rs
 .sp 2
 .sz 14
 .ft B
 .ce 2

-An Introductory 4.3BSD
+An Introductory 4.4BSD

 Interprocess Communication Tutorial
 .sz 10
 .sp 2
 Interprocess Communication Tutorial
 .sz 10
 .sp 2


@@ -30,14 +31,15 @@ University of California, Berkeley
 .sp
 .(c
 .pp
 .sp
 .(c
 .pp

-Berkeley UNIX\(dg 4.3BSD offers several choices for interprocess communication.
-To aid the programmer in  developing programs comprising cooperating
+Berkeley UNIX\(dg 4.4BSD offers several choices for interprocess communication.
+To aid the programmer in  developing programs which are comprised of
+cooperating

 processes, the different choices are discussed and a series of example 
 programs are presented.  These programs
 processes, the different choices are discussed and a series of example 
 programs are presented.  These programs

-demonstrate in a simple way the use of pipes, socketpairs, and sockets
+demonstrate in a simple way the use of pipes, socketpairs, sockets

 and the use of datagram and stream communication.  The intent of this
 document is to present a few simple example programs, not to describe the
 and the use of datagram and stream communication.  The intent of this
 document is to present a few simple example programs, not to describe the

-networking system in full generality.
+networking system in full.

 .)c
 .sp 2
 .(f
 .)c
 .sp 2
 .(f


@@ -47,41 +49,38 @@ networking system in full generality.
 .sh 1 "Goals"
 .r
 .pp
 .sh 1 "Goals"
 .r
 .pp

-UNIX is an operating system that supports processes.  Processes
-sit in their own little worlds off on their own machines and generally
-just compute. 
-Occasionally it has been reasonable to 
-write programs as small modular pieces that
-talk to each other, since the resulting facilities can be flexible and
-easy to modify.
-More recently, with more computers sitting around in the same buildings
-people have had the idea that
-it would be nice if a process on one machine could talk to a process
-on another machine.  For example these processes might relay commands
-typed by the user across machine boundaries, allowing the user to
-log into a different computer without walking to a new terminal,
-rewiring the old terminal, or taking other time consuming actions.  
-These ideas have been integrated and abstracted yielding an interface
-for interprocess communication, or IPC.
-.pp
+Facilities for interprocess communication (IPC) and networking
+were a major addition to UNIX in the Berkeley UNIX 4.2BSD release.
+These facilities required major additions and some changes
+to the system interface.

 The basic idea of this interface is to make IPC similar to file I/O.
 In UNIX a process has a set of I/O descriptors, from which one reads
 and to which one writes.
 The basic idea of this interface is to make IPC similar to file I/O.
 In UNIX a process has a set of I/O descriptors, from which one reads
 and to which one writes.

+Descriptors may refer to normal files, to devices (including terminals),
+or to communication channels.

 The use of a descriptor has three phases: its creation,
 its use for reading and writing, and its destruction.  By using descriptors
 to write files, rather than simply naming the target file in the write
 The use of a descriptor has three phases: its creation,
 its use for reading and writing, and its destruction.  By using descriptors
 to write files, rather than simply naming the target file in the write

-call, one gains a surprising amount of flexibility.  Often the program that
+call, one gains a surprising amount of flexibility.  Often, the program that

 creates a descriptor will be different from the program that uses the
 descriptor.  For example the shell can create a descriptor for the output 
 of the `ls'
 command that will cause the listing to appear in a file rather than
 creates a descriptor will be different from the program that uses the
 descriptor.  For example the shell can create a descriptor for the output 
 of the `ls'
 command that will cause the listing to appear in a file rather than

-on a terminal.  The use of descriptors is not the only communication mechanism
+on a terminal.
+Pipes are another form of descriptor that have been used in UNIX
+for some time.
+Pipes allow one-way data transmission from one process
+to another; the two processes and the pipe must be set up by a common
+ancestor.
+.pp
+The use of descriptors is not the only communication interface

 provided by UNIX.
 provided by UNIX.

-There is another mechanism to flash a tiny amount of information from one 
-process to another, telling it, for example, that someone wants it to stop.  
-This is called sending a signal.  To signal
-another process one states explicitly the identity of the recipient.
-This requirement limits the flexibility of the signaling mechanism
+The signal mechanism sends a tiny amount of information from one 
+process to another.
+The signaled process receives only the signal type,
+not the identity of the sender,
+and the number of possible signals is small.
+The signal semantics limit the flexibility of the signaling mechanism

 as a means of interprocess communication.
 .pp
 The identification of IPC with I/O is quite longstanding in UNIX and
 as a means of interprocess communication.
 .pp
 The identification of IPC with I/O is quite longstanding in UNIX and


@@ -92,7 +91,8 @@ has necessitated some change in the way that descriptors are created.
 Additionally, new possibilities for the meaning of read and write have
 been admitted.  Originally the meanings, or semantics, of these terms
 were fairly simple.  When you wrote something it was delivered.  When
 Additionally, new possibilities for the meaning of read and write have
 been admitted.  Originally the meanings, or semantics, of these terms
 were fairly simple.  When you wrote something it was delivered.  When

-you read, you blocked until the data arrived.  Other possibilities exist,
+you read something, you were blocked until the data arrived.
+Other possibilities exist,

 however.  One can write without full assurance of delivery if one can
 check later to catch occasional failures.  Messages can be kept as
 discrete units or merged into a stream. 
 however.  One can write without full assurance of delivery if one can
 check later to catch occasional failures.  Messages can be kept as
 discrete units or merged into a stream. 


@@ -100,7 +100,7 @@ One can ask to read, but insist on not waiting if nothing is immediately
 available.  These new possibilities are allowed in the Berkeley UNIX IPC
 interface.  
 .pp
 available.  These new possibilities are allowed in the Berkeley UNIX IPC
 interface.  
 .pp

-Thus Berkeley UNIX 4.3BSD offers several choices for IPC.
+Thus Berkeley UNIX 4.4BSD offers several choices for IPC.

 This paper presents simple examples that illustrate some of
 the choices.
 The reader is presumed to be familiar with the C programming language
 This paper presents simple examples that illustrate some of
 the choices.
 The reader is presumed to be familiar with the C programming language


@@ -108,7 +108,7 @@ The reader is presumed to be familiar with the C programming language
 but not necessarily with the system calls of the UNIX system or with
 processes and interprocess communication.
 The paper reviews the notion of a process and the types of
 but not necessarily with the system calls of the UNIX system or with
 processes and interprocess communication.
 The paper reviews the notion of a process and the types of

-communication that are supported by Berkeley UNIX 4.3BSD.
+communication that are supported by Berkeley UNIX 4.4BSD.

 A series of examples are presented that create processes that communicate
 with one another.  The programs show different ways of establishing
 channels of communication.
 A series of examples are presented that create processes that communicate
 with one another.  The programs show different ways of establishing
 channels of communication.


@@ -117,7 +117,7 @@ To clearly present how communication can take place,
 the example programs have been cleared of anything that
 might be construed as useful work.
 They can, therefore, serve as models
 the example programs have been cleared of anything that
 might be construed as useful work.
 They can, therefore, serve as models

-for the programmer trying to construct programs comprising
+for the programmer trying to construct programs which are comprised of 

 cooperating processes.
 .b
 .sh 1 "Processes"
 cooperating processes.
 .b
 .sh 1 "Processes"


@@ -126,11 +126,11 @@ A \fIprogram\fP is both a sequence of statements and a rough way of referring
 to the computation that occurs when the compiled statements are run.
 A \fIprocess\fP can be thought of as a single line of control in a program.
 Most programs execute some statements, go through a few loops, branch in
 to the computation that occurs when the compiled statements are run.
 A \fIprocess\fP can be thought of as a single line of control in a program.
 Most programs execute some statements, go through a few loops, branch in

-various directions and then end.  They are single process programs.
+various directions and then end.  These are single process programs.

 Programs can also have a point where control splits into two independent lines,
 an action called \fIforking.\fP
 In UNIX these lines can never join again.  A call to the system routine 
 Programs can also have a point where control splits into two independent lines,
 an action called \fIforking.\fP
 In UNIX these lines can never join again.  A call to the system routine 

-\fIfork()\fP causes a process to split in this way.
+\fIfork()\fP, causes a process to split in this way.

 The result of this call is that two independent processes will be
 running, executing exactly the same code.
 Memory values will be the same for all values set before the fork, but,
 The result of this call is that two independent processes will be
 running, executing exactly the same code.
 Memory values will be the same for all values set before the fork, but,


@@ -167,15 +167,15 @@ This is called ``piping'' the output of one program
 to another because the mechanism used to transfer the output is called a
 pipe.
 When the user types a command, the command is read by the shell, which
 to another because the mechanism used to transfer the output is called a
 pipe.
 When the user types a command, the command is read by the shell, which

-decides how to execute it.  If the command is simple, for example
+decides how to execute it.  If the command is simple, for example,

 .i "``prog1,''"
 .i "``prog1,''"

-the shell forks a process, which executes the program prog1 and then dies.
+the shell forks a process, which executes the program, prog1, and then dies.

 The shell waits for this termination and then prompts for the next
 command.
 If the command is a compound command,
 .i "``prog1 | prog2,''"
 the shell creates two processes connected by a pipe. One process
 The shell waits for this termination and then prompts for the next
 command.
 If the command is a compound command,
 .i "``prog1 | prog2,''"
 the shell creates two processes connected by a pipe. One process

-runs the program prog1, the other runs prog2.  The pipe is an I/O
+runs the program, prog1, the other runs prog2.  The pipe is an I/O

 mechanism with two ends, or sockets.  Data that is written into one socket
 can be read from the other.  
 .(z
 mechanism with two ends, or sockets.  Data that is written into one socket
 can be read from the other.  
 .(z


@@ -215,18 +215,19 @@ returned in the low word of the array is opened for reading only,
 while the socket in the high end is opened only for writing.
 This corresponds to the fact that the standard input is the first
 descriptor of a process's descriptor table and the standard output
 while the socket in the high end is opened only for writing.
 This corresponds to the fact that the standard input is the first
 descriptor of a process's descriptor table and the standard output

-the second.  After creating the pipe, the parent creates the child 
+is the second.  After creating the pipe, the parent creates the child 

 with which it will share the pipe by calling \fIfork().\fP
 Figure 2 illustrates the effect of a fork.
 The parent process's descriptor table points to both ends of the pipe.
 with which it will share the pipe by calling \fIfork().\fP
 Figure 2 illustrates the effect of a fork.
 The parent process's descriptor table points to both ends of the pipe.

-After the fork, both parent's and child's descriptor table point to
+After the fork, both parent's and child's descriptor tables point to

 the pipe.
 The child can then use the pipe to send a message to the parent.
 .(z
 the pipe.
 The child can then use the pipe to send a message to the parent.
 .(z

--
-.bl 5.8i
--
-.\" pipe.grn goes here
+.ns
+.GS C
+height 6i
+file pipe.grn
+.GE

 .sp
 .ce 1
 Figure 2\ \ Sharing a pipe between parent and child
 .sp
 .ce 1
 Figure 2\ \ Sharing a pipe between parent and child


@@ -242,21 +243,22 @@ from child to parent would be possible (since both processes have
 references to both ends), but very complicated.
 If the parent and child are to have a two-way conversation,
 the parent creates two pipes, one for use in each direction.
 references to both ends), but very complicated.
 If the parent and child are to have a two-way conversation,
 the parent creates two pipes, one for use in each direction.

-(In accordance with their plans both parent and child in the example above
+(In accordance with their plans, both parent and child in the example above

 close the socket that they will not use.  It is not required that unused
 descriptors be closed, but it is good practice.)
 close the socket that they will not use.  It is not required that unused
 descriptors be closed, but it is good practice.)

-A pipe is also a \fIstream\fP communication mechanism, that
-is all messages sent through the pipe are placed in order
-and reliably delivered.  When the reader asks for some number of bytes of this
+A pipe is also a \fIstream\fP communication mechanism; that
+is, all messages sent through the pipe are placed in order
+and reliably delivered.  When the reader asks for a certain
+number of bytes from this

 stream, he is given as many bytes as are available, up
 stream, he is given as many bytes as are available, up

-to the amount of the request.  Note that this pays no attention
-to whether those bytes all came from the same call to \fIwrite()\fP
-or came from several calls to \fIwrite()\fP but were concatenated.
+to the amount of the request. Note that these bytes may have come from 
+the same call to \fIwrite()\fR or from several calls to \fIwrite()\fR
+which were concatenated.

 .b
 .sh 1 "Socketpairs"
 .r
 .pp
 .b
 .sh 1 "Socketpairs"
 .r
 .pp

-Berkeley UNIX 4.3BSD provides a slight generalization of pipes.  A pipe is a
+Berkeley UNIX 4.4BSD provides a slight generalization of pipes.  A pipe is a

 pair of connected sockets for one-way stream communication.  One may
 obtain a pair of connected sockets for two-way stream communication
 by calling the routine \fIsocketpair().\fP
 pair of connected sockets for one-way stream communication.  One may
 obtain a pair of connected sockets for two-way stream communication
 by calling the routine \fIsocketpair().\fP


@@ -281,8 +283,6 @@ domain, called the UNIX domain.
 The UNIX domain uses UNIX path names for naming sockets.  
 It only allows communication
 between sockets on the same machine.
 The UNIX domain uses UNIX path names for naming sockets.  
 It only allows communication
 between sockets on the same machine.

-A style of communication is a statement about the semantics that
-are desired.

 .pp
 Note that the header files 
 .i "<sys/socket.h>"
 .pp
 Note that the header files 
 .i "<sys/socket.h>"


@@ -302,10 +302,10 @@ for some of its definitions.
 Figure 3\ \ Use of a socketpair
 .)z
 .(z
 Figure 3\ \ Use of a socketpair
 .)z
 .(z

--
-.bl 5.8i
--
-.\" socketpair.grn goes here
+.GS C
+height 6i
+file socketpair.grn
+.GE

 .sp
 .ce 1
 Figure 4\ \ Sharing a socketpair between parent and child
 .sp
 .ce 1
 Figure 4\ \ Sharing a socketpair between parent and child


@@ -317,14 +317,15 @@ Figure 4\ \ Sharing a socketpair between parent and child
 Pipes and socketpairs are a simple solution for communicating between
 a parent and child or between child processes.
 What if we wanted to have processes that have no common ancestor
 Pipes and socketpairs are a simple solution for communicating between
 a parent and child or between child processes.
 What if we wanted to have processes that have no common ancestor

-to communicate?  Neither standard UNIX pipes nor socketpairs are
+with whom to set up communication?
+Neither standard UNIX pipes nor socketpairs are

 the answer here, since both mechanisms require a common ancestor to
 set up the communication.
 We would like to have two processes separately create sockets
 and then have messages sent between them.  This is often the
 case when providing or using a service in the system.  This is
 also the case when the communicating processes are on separate machines.
 the answer here, since both mechanisms require a common ancestor to
 set up the communication.
 We would like to have two processes separately create sockets
 and then have messages sent between them.  This is often the
 case when providing or using a service in the system.  This is
 also the case when the communicating processes are on separate machines.

-In Berkeley UNIX 4.3BSD one can create individual sockets, give them names and
+In Berkeley UNIX 4.4BSD one can create individual sockets, give them names and

 send messages between them.
 .pp
 Sockets created by different programs use names to refer to one another;
 send messages between them.
 .pp
 Sockets created by different programs use names to refer to one another;


@@ -375,7 +376,7 @@ generally less important than the difference in semantics.  The
 performance gain that one might find in using datagrams must be weighed
 against the increased complexity of the program, which must now concern
 itself with lost or out of order messages.  If lost messages may simply be 
 performance gain that one might find in using datagrams must be weighed
 against the increased complexity of the program, which must now concern
 itself with lost or out of order messages.  If lost messages may simply be 

-ignored, the quantity of traffic may be a consideration; the expense
+ignored, the quantity of traffic may be a consideration. The expense

 of setting up a connection is best justified by frequent use of the connection.
 Since the performance of a protocol changes as it is tuned for different
 situations, it is best to seek the most up-to-date information when
 of setting up a connection is best justified by frequent use of the connection.
 Since the performance of a protocol changes as it is tuned for different
 situations, it is best to seek the most up-to-date information when


@@ -394,7 +395,7 @@ It is possible for several protocols, differing only in low level
 details, to implement the same style of communication within
 a particular domain.  Although it is possible to select
 which protocol should be used, for nearly all uses it is sufficient to
 details, to implement the same style of communication within
 a particular domain.  Although it is possible to select
 which protocol should be used, for nearly all uses it is sufficient to

-request the default protocol.  This has been done in all the example
+request the default protocol.  This has been done in all of the example

 programs.
 .pp
 One specifies the domain, style and protocol of a socket when
 programs.
 .pp
 One specifies the domain, style and protocol of a socket when


@@ -409,7 +410,7 @@ in the UNIX domain.
 .so udgramread.c
 .ft
 .ce 1
 .so udgramread.c
 .ft
 .ce 1

-Figure 5a\ \ Reading using UNIX domain datagrams
+Figure 5a\ \ Reading UNIX domain datagrams

 .)z
 .pp
 Let us now look at two programs that create sockets separately.
 .)z
 .pp
 Let us now look at two programs that create sockets separately.


@@ -426,7 +427,7 @@ system call \fIbind().\fP
 The program in Figure 5a uses the name ``socket'',
 which it binds to its socket.
 This name will appear in the working directory of the program.
 The program in Figure 5a uses the name ``socket'',
 which it binds to its socket.
 This name will appear in the working directory of the program.

-The routines in Figure 5b uses its
+The routines in Figure 5b use its

 socket only for sending messages.  It does not create a name for
 the socket because no other process has to refer to it.  
 .(z
 socket only for sending messages.  It does not create a name for
 the socket because no other process has to refer to it.  
 .(z


@@ -445,7 +446,8 @@ When a name is bound into the name space, a file (inode) is allocated in the
 file system.  If
 the inode is not deallocated, the name will continue to exist even after
 the bound socket is closed.  This can cause subsequent runs of a program
 file system.  If
 the inode is not deallocated, the name will continue to exist even after
 the bound socket is closed.  This can cause subsequent runs of a program

-to find that a name is unavailable, and directories to fill up with these
+to find that a name is unavailable, and can cause 
+directories to fill up with these

 objects.  The names are removed by calling \fIunlink()\fP or using
 the \fIrm\fP\|(1) command.
 Names in the UNIX domain are only used for rendezvous.  They are not used
 objects.  The names are removed by calling \fIunlink()\fP or using
 the \fIrm\fP\|(1) command.
 Names in the UNIX domain are only used for rendezvous.  They are not used


@@ -456,7 +458,7 @@ not) automatically given addresses when they are connected.
 There is no established means of communicating names to interested
 parties.  In the example, the program in Figure 5b gets the
 name of the socket to which it will send its message through its
 There is no established means of communicating names to interested
 parties.  In the example, the program in Figure 5b gets the
 name of the socket to which it will send its message through its

-command line arguments.  Once a line of communication has been created
+command line arguments.  Once a line of communication has been created,

 one can send the names of additional, perhaps new, sockets over the link.
 Facilities will have to be built that will make the distribution of
 names less of a problem than it now is.
 one can send the names of additional, perhaps new, sockets over the link.
 Facilities will have to be built that will make the distribution of
 names less of a problem than it now is.


@@ -468,7 +470,7 @@ names less of a problem than it now is.
 .so dgramread.c
 .ft
 .ce 1
 .so dgramread.c
 .ft
 .ce 1

-Figure 6a\ \ Reading using Internet domain datagrams
+Figure 6a\ \ Reading Internet domain datagrams

 .)z
 .pp
 The examples in Figure 6a and 6b are very close to the previous example
 .)z
 .pp
 The examples in Figure 6a and 6b are very close to the previous example


@@ -495,7 +497,7 @@ of a pair of communicating sockets.
 An association is thus identified by the tuple
 <\fIprotocol, local machine address, local port,
 remote machine address, remote port\fP>.
 An association is thus identified by the tuple
 <\fIprotocol, local machine address, local port,
 remote machine address, remote port\fP>.

-An association may transient when using datagram sockets;
+An association may be transient when using datagram sockets;

 the association actually exists during a \fIsend\fP operation.
 .(z
 .ft CW
 the association actually exists during a \fIsend\fP operation.
 .(z
 .ft CW


@@ -519,7 +521,8 @@ to receive from ``anywhere,'' but one cannot send a message ``anywhere.''
 The program in Figure 6b is given the destination host name as a command
 line argument.
 To determine a network address to which it can send the message, it looks
 The program in Figure 6b is given the destination host name as a command
 line argument.
 To determine a network address to which it can send the message, it looks

-the host address up by the call to \fIgethostbyname()\fP.
+up
+the host address by the call to \fIgethostbyname()\fP.

 The returned structure includes the host's network address,
 which is copied into the structure specifying the
 destination of the message.
 The returned structure includes the host's network address,
 which is copied into the structure specifying the
 destination of the message.


@@ -569,7 +572,7 @@ To initiate a connection, this program simply creates
 a stream socket, then calls \fIconnect()\fP,
 specifying the address of the socket to which
 it wishes its socket connected.  Provided that the target socket exists and
 a stream socket, then calls \fIconnect()\fP,
 specifying the address of the socket to which
 it wishes its socket connected.  Provided that the target socket exists and

-is prepared to handle a connection, connection will complete,
+is prepared to handle a connection, connection will be complete,

 and the program can begin to send
 messages.  Messages will be delivered in order without message
 boundaries, as with pipes.  The connection is destroyed when either
 and the program can begin to send
 messages.  Messages will be delivered in order without message
 boundaries, as with pipes.  The connection is destroyed when either


@@ -601,10 +604,10 @@ Figure 7b\ \ Accepting an Internet domain stream connection
 Figure 7c\ \ Using select() to check for pending connections
 .)z
 .(z
 Figure 7c\ \ Using select() to check for pending connections
 .)z
 .(z

--
-.bl 5.8i
--
-.\" accept.grn goes here
+.GS C
+height 6i
+file accept.grn
+.GE

 .sp
 .ce 1
 Figure 8\ \ Establishing a stream connection
 .sp
 .ce 1
 Figure 8\ \ Establishing a stream connection


@@ -642,7 +645,7 @@ Once the listen call has been completed, the program enters
 an infinite loop.  On each pass through the loop, a new connection is
 accepted and removed from the queue, and, hence, a new socket for the 
 connection is created.  The bottom half of Figure 8 shows the result of
 an infinite loop.  On each pass through the loop, a new connection is
 accepted and removed from the queue, and, hence, a new socket for the 
 connection is created.  The bottom half of Figure 8 shows the result of

-Process 1 connecting with the named socket of Process 2 and Process 2
+Process 1 connecting with the named socket of Process 2, and Process 2

 accepting the connection.  After the connection is created, the
 service, in this case printing out the messages, is performed and the
 connection socket closed.  The \fIaccept()\fP
 accepting the connection.  After the connection is created, the
 service, in this case printing out the messages, is performed and the
 connection socket closed.  The \fIaccept()\fP


@@ -687,7 +690,7 @@ Figure 9b\ \ Accepting a UNIX domain stream connection
 .sh 1 "Reads, Writes, Recvs, etc."
 .r
 .pp
 .sh 1 "Reads, Writes, Recvs, etc."
 .r
 .pp

-UNIX 4.3BSD has several system calls for reading and writing information.
+UNIX 4.4BSD has several system calls for reading and writing information.

 The simplest calls are \fIread() \fP and \fIwrite().\fP \fIWrite()\fP
 takes as arguments the index of a descriptor, a pointer to a buffer 
 containing the data and the size of the data.
 The simplest calls are \fIread() \fP and \fIwrite().\fP \fIWrite()\fP
 takes as arguments the index of a descriptor, a pointer to a buffer 
 containing the data and the size of the data.


@@ -812,7 +815,7 @@ Figure 10\ \ Varieties of read and write commands
 .pp
 This paper has presented examples of some of the forms
 of communication supported by
 .pp
 This paper has presented examples of some of the forms
 of communication supported by

-Berkeley UNIX 4.3BSD.  These have been presented in an order chosen for
+Berkeley UNIX 4.4BSD.  These have been presented in an order chosen for

 ease of presentation.  It is useful to review these options emphasizing the
 factors that make each attractive.
 .pp
 ease of presentation.  It is useful to review these options emphasizing the
 factors that make each attractive.
 .pp


@@ -839,7 +842,7 @@ as there are usually only 64 entries available in the open descriptor
 table.  This can cause problems if a single server must talk with a large
 number of clients. 
 Another is that for delivering a short message the stream setup and 
 table.  This can cause problems if a single server must talk with a large
 number of clients. 
 Another is that for delivering a short message the stream setup and 

-teardown time can be unnecessarily large.  Weighed against this are
+teardown time can be unnecessarily long.  Weighed against this are

 the reliability built into the streams.  This will often be the
 deciding factor in favor of streams.
 .b
 the reliability built into the streams.  This will often be the
 deciding factor in favor of streams.
 .b


@@ -855,7 +858,7 @@ be added.
 .pp
 An introduction to the UNIX system and programming using UNIX system calls
 can be found in [Kernighan and Pike 1984].
 .pp
 An introduction to the UNIX system and programming using UNIX system calls
 can be found in [Kernighan and Pike 1984].

-Further documentation of the Berkeley UNIX 4.3BSD IPC mechanisms can be 
+Further documentation of the Berkeley UNIX 4.4BSD IPC mechanisms can be 

 found in [Leffler et al. 1986].
 More detailed information about particular calls and protocols
 is provided in sections
 found in [Leffler et al. 1986].
 More detailed information about particular calls and protocols
 is provided in sections


@@ -907,14 +910,14 @@ Englewood Cliffs, N.J.: Prentice-Hall.
 .sp
 .ls 1
 S.J. Leffler, R.S. Fabry, W.N. Joy, P. Lapsley, S. Miller & C. Torek, 1986,
 .sp
 .ls 1
 S.J. Leffler, R.S. Fabry, W.N. Joy, P. Lapsley, S. Miller & C. Torek, 1986,

-.i "An Advanced 4.3BSD Interprocess Communication Tutorial."
+.i "An Advanced 4.4BSD Interprocess Communication Tutorial."

 Computer Systems Research Group,
 Department of Electrical Engineering and Computer Science,
 University of California, Berkeley.
 .sp
 .ls 1
 Computer Systems Research Group, 1986,
 Computer Systems Research Group,
 Department of Electrical Engineering and Computer Science,
 University of California, Berkeley.
 .sp
 .ls 1
 Computer Systems Research Group, 1986,

-.i "UNIX Programmer's Manual, 4.3 Berkeley Software Distribution."
+.i "UNIX Programmer's Manual, 4.4 Berkeley Software Distribution."

 Computer Systems Research Group,
 Department of Electrical Engineering and Computer Science,
 University of California, Berkeley.
 Computer Systems Research Group,
 Department of Electrical Engineering and Computer Science,
 University of California, Berkeley.