tutor.me

早期freebsd实现

.)z
.pp
Forming a connection is asymmetrical; one process, such as the
program in Figure 7a, requests a connection with a particular socket,
the other process accepts connection requests.
Before a connection can be accepted a socket must be created and an address
bound to it.  This
situation is illustrated in the top half of Figure 8.  Process 2
has created a socket and bound a port number to it.  Process 1 has created an
unnamed socket.
The address bound to process 2's socket is then made known to process 1 and, 
perhaps to several other potential communicants as well.
If there are several possible communicants,
this one socket might receive several requests for connections.
As a result, a new socket is created for each connection.  This new socket
is the endpoint for communication within this process for this connection.
A connection may be destroyed by closing the corresponding socket.
.pp
The program in Figure 7b is a rather trivial example of a server.  It 
creates a socket to which it binds a name, which it then advertises.
(In this case it prints out the socket number.)  The program then calls
\fIlisten()\fP for this socket.  
Since several clients may attempt to connect more or less
simultaneously, a queue of pending connections is maintained in the system
address space.  \fIListen()\fP
marks the socket as willing to accept connections and initializes the queue.
When a connection is requested, it is listed in the queue.  If the
queue is full, an error status may be returned to the requester.
The maximum length of this queue is specified by the second argument of
\fIlisten()\fP; the maximum length is limited by the system.  
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
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
call will take a pending connection
request from the queue if one is available, or block waiting for a request.
Messages are read from the connection socket.
Reads from an active connection will normally block until data is available.
The number of bytes read is returned.  When a connection is destroyed,
the read call returns immediately.  The number of bytes returned will
be zero.
.pp
The program in Figure 7c is a slight variation on the server in Figure 7b.
It avoids blocking when there are no pending connection requests by 
calling \fIselect()\fP
to check for pending requests before calling \fIaccept().\fP
This strategy is useful when connections may be received
on more than one socket, or when data may arrive on other connected
sockets before another connection request.
.pp
The programs in Figures 9a and 9b show a program using stream communication
in the UNIX domain.  Streams in the UNIX domain can be used for this sort
of program in exactly the same way as Internet domain streams, except for
the form of the names and the restriction of the connections to a single
file system.  There are some differences, however, in the functionality of 
streams in the two domains, notably in the handling of 
\fIout-of-band\fP data (discussed briefly below).  These differences
are beyond the scope of this paper.
.(z
.ft CW
.so ustreamwrite.c
.ft
.ce 1
Figure 9a\ \ Initiating a UNIX domain stream connection
.sp 2
.ft CW
.so ustreamread.c
.ft
.ce 1
Figure 9b\ \ Accepting a UNIX domain stream connection
.)z
.b
.sh 1 "Reads, Writes, Recvs, etc."
.r
.pp
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 descriptor may indicate either a file or a connected socket.  
``Connected'' can mean either a connected stream socket (as described
in Section 8) or a datagram socket for which a \fIconnect()\fP
call has provided a default destination (see the \fIconnect()\fP manual page).
\fIRead()\fP also takes a descriptor that indicates either a file or a socket.
\fIWrite()\fP requires a connected socket since no destination is 
specified in the parameters of the system call.
\fIRead()\fP can be used for either a connected or an unconnected socket.
These calls are, therefore, quite flexible and may be used to
write applications that require no assumptions about the source of
their input or the destination of their output.
There are variations on \fIread() \fP and \fIwrite()\fP
that allow the source and destination of the input and output to use
several separate buffers, while retaining the flexibility to handle
both files and sockets.  These are \fIreadv()\fP and \fI writev(),\fP
for read and write \fIvector.\fP
.pp 
It is sometimes necessary to send high priority data over a
connection that may have unread low priority data at the
other end.  For example, a user interface process may be interpreting
commands and sending them on to another process through a stream connection.
The user interface may have filled the stream with as yet unprocessed 
requests when the user types
a command to cancel all outstanding requests.
Rather than have the high priority data wait
to be processed after the low priority data, it is possible to
send it as \fIout-of-band\fP
(OOB) data.  The notification of pending OOB data results in the generation of
a SIGURG signal, if this signal has been enabled (see the manual
page for \fIsignal\fP or \fIsigvec\fP).
See [Leffler 1986] for a more complete description of the OOB mechanism.
There are a pair of calls similar to \fIread\fP and \fIwrite\fP
that allow options, including sending 
and receiving OOB information; these are \fI send()\fP
and \fIrecv().\fP
These calls are used only with sockets; specifying a descriptor for a file will
result in the return of an error status.  These calls also allow
\fIpeeking\fP at data in a stream.
That is, they allow a process to read data without removing the data from
the stream.  One use of this facility is to read ahead in a stream
to determine the size of the next item to be read.
When not using these options, these calls have the same functions as 
\fIread()\fP and \fIwrite().\fP
.pp
To send datagrams, one must be allowed to specify the destination.
The call \fIsendto()\fP
takes a destination address as an argument and is therefore used for
sending datagrams.  The call \fIrecvfrom()\fP
is often used to read datagrams, since this call returns the address
of the sender, if it is available, along with the data.
If the identity of the sender does not matter, one may use \fIread()\fP
or \fIrecv().\fP
.pp
Finally, there are a pair of calls that allow the sending and
receiving of messages from multiple buffers, when the address of the
recipient must be specified.  These are \fIsendmsg()\fP and 
\fIrecvmsg().\fP
These calls are actually quite general and have other uses,
including, in the UNIX domain, the transmission of a file descriptor from one
process to another.
.pp
The various options for reading and writing are shown in Figure 10,
together with their parameters.  The parameters for each system call
reflect the differences in function of the different calls.
In the examples given in this paper, the calls \fIread()\fP and 
\fIwrite()\fP have been used whenever possible.
.(z
.ft CW
	/*
	 * The variable descriptor may be the descriptor of either a file
	 * or of a socket.
	 */
	cc = read(descriptor, buf, nbytes)
	int cc, descriptor; char *buf; int nbytes;

	/*
	 * An iovec can include several source buffers.
	 */
	cc = readv(descriptor, iov, iovcnt)
	int cc, descriptor; struct iovec *iov; int iovcnt;

	cc = write(descriptor, buf, nbytes)
	int cc, descriptor; char *buf; int nbytes;

	cc = writev(descriptor, iovec, ioveclen)
	int cc, descriptor; struct iovec *iovec; int ioveclen;

	/*
	 * The variable ``sock'' must be the descriptor of a socket.
	 * Flags may include MSG_OOB and MSG_PEEK.
	 */
	cc = send(sock, msg, len, flags)
	int cc, sock; char *msg; int len, flags; 

	cc = sendto(sock, msg, len, flags, to, tolen)
	int cc, sock; char *msg; int len, flags;
	struct sockaddr *to; int tolen;

	cc = sendmsg(sock, msg, flags)
	int cc, sock; struct msghdr msg[]; int flags;

	cc = recv(sock, buf, len, flags)
	int cc, sock; char *buf; int len, flags;

	cc = recvfrom(sock, buf, len, flags, from, fromlen)
	int cc, sock; char *buf; int len, flags;
	struct sockaddr *from; int *fromlen;

	cc = recvmsg(sock, msg, flags)
	int cc, socket; struct msghdr msg[]; int flags;
.ft
.sp 1
.ce 1
Figure 10\ \ Varieties of read and write commands
.)z
.b
.sh 1 "Choices"
.r
.pp
This paper has presented examples of some of the forms
of communication supported by
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
Pipes have the advantage of portability, in that they are supported in all
UNIX systems.  They also are relatively
simple to use.  Socketpairs share this simplicity and have the additional
advantage of allowing bidirectional communication.  The major shortcoming
of these mechanisms is that they require communicating processes to be
descendants of a common process.  They do not allow intermachine communication.
.pp
The two communication domains, UNIX and Internet, allow processes with no common
ancestor to communicate.
Of the two, only the Internet domain allows
communication between machines.
This makes the Internet domain a necessary
choice for processes running on separate machines.
.pp
The choice between datagrams and stream communication is best made by
carefully considering the semantic and performance
requirements of the application.
Streams can be both advantageous and disadvantageous.  One disadvantage
is that a process is only allowed a limited number of open streams,
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 
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
.sh 1 "What to do Next"
.r
.pp
Many of the examples presented here can serve as models for multiprocess
programs and for programs distributed across several machines.  
In developing a new multiprocess program, it is often easiest to 
first write the code to create the processes and communication paths.
After this code is debugged, the code specific to the application can
be added.
.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.4BSD IPC mechanisms can be 
found in [Leffler et al. 1986].
More detailed information about particular calls and protocols
is provided in sections
2, 3 and 4 of the
UNIX Programmer's Manual [CSRG 1986].
In particular the following manual pages are relevant:
.(b
.TS
l l.
creating and naming sockets	socket(2), bind(2)
establishing connections	listen(2), accept(2), connect(2)
transferring data	read(2), write(2), send(2), recv(2)
addresses	inet(4F)
protocols	tcp(4P), udp(4P).
.TE
.)b
.(b
.sp
.b
Acknowledgements
.pp
I would like to thank Sam Leffler and Mike Karels for their help in
understanding the IPC mechanisms and all the people whose comments 
have helped in writing and improving this report.
.pp
This work was sponsored by the Defense Advanced Research Projects Agency
(DoD), ARPA Order No. 4031, monitored by the Naval Electronics Systems
Command under contract No. N00039-C-0235. 
The views and conclusions contained in this document are those of the
author and should not be interpreted as representing official policies,
either expressed or implied, of the Defense Research Projects Agency
or of the US Government.
.)b
.(b
.sp
.b
References
.r
.sp
.ls 1
B.W. Kernighan & R. Pike, 1984,
.i "The UNIX Programming Environment."
Englewood Cliffs, N.J.: Prentice-Hall.
.sp
.ls 1
B.W. Kernighan & D.M. Ritchie, 1978,
.i "The C Programming Language,"
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,
.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,
.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.
.)b