tutor.me

早期freebsd实现

.i "<sys/socket.h>,"
which in turn requires the file 
.i "<sys/types.h>"
for some of its definitions.
.(z
.ft CW
.so socketpair.c
.ft
.ce 1
Figure 3\ \ Use of a socketpair
.)z
.(z
.so fig3.pic
.ce 1
Figure 4\ \ Sharing a socketpair between parent and child
.)z
.b
.sh 1 "Domains and Protocols"
.r
.pp
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
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.
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;
names generally must be translated into addresses for use.
The space from which an address is drawn is referred to as a
.i domain.
There are several domains for sockets.
Two that will be used in the examples here are the UNIX domain (or AF_UNIX,
for Address Format UNIX) and the Internet domain (or AF_INET).
UNIX domain IPC is an experimental facility in 4.2BSD and 4.3BSD.
In the UNIX domain, a socket is given a path name within the file system
name space.
A file system node is created for the socket and other processes may 
then refer to the socket by giving the proper pathname.
UNIX domain names, therefore, allow communication between any two processes
that work in the same file system.
The Internet domain is the UNIX implementation of the DARPA Internet
standard protocols IP/TCP/UDP.
Addresses in the Internet domain consist of a machine network address
and an identifying number, called a port.
Internet domain names allow communication between machines.
.pp
Communication follows some particular ``style.''
Currently, communication is either through a \fIstream\fP
or by \fIdatagram.\fP
Stream communication implies several things.  Communication takes
place across a connection between two sockets.  The communication
is reliable, error-free, and, as in pipes, no message boundaries are
kept. Reading from a stream may result in reading the data sent from
one or several calls to \fIwrite()\fP
or only part of the data from a single call, if there is not enough room
for the entire message, or if not all the data from a large message
has been transferred.
The protocol implementing such a style will retransmit messages
received with errors. It will also return error messages if one tries to
send a message after the connection has been broken.
Datagram communication does not use connections.  Each message is
addressed individually.  If the address is correct, it will generally
be received, although this is not guaranteed.  Often datagrams are
used for requests that require a response from the 
recipient.  If no response
arrives in a reasonable amount of time, the request is repeated.
The individual datagrams will be kept separate when they are read, that
is, message boundaries are preserved.
.pp
The difference in performance between the two styles of communication is 
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 
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
making choices for a program in which performance is crucial.
.pp
A protocol is a set of rules, data formats and conventions that regulate the
transfer of data between participants in the communication.
In general, there is one protocol for each socket type (stream,
datagram, etc.) within each domain.
The code that implements a protocol 
keeps track of the names that are bound to sockets,
sets up connections and	transfers data between sockets,
perhaps sending the data across a network.
This code also keeps track of the names that are bound to sockets.
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
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
it is created.  For example, in Figure 5a the call to \fIsocket()\fP
causes the creation of a datagram socket with the default protocol 
in the UNIX domain.
.b
.sh 1 "Datagrams in the UNIX Domain"
.r
.(z
.ft CW
.so udgramread.c
.ft
.ce 1
Figure 5a\ \ Reading UNIX domain datagrams
.)z
.pp
Let us now look at two programs that create sockets separately.
The programs in Figures 5a and 5b use datagram communication
rather than a stream.  
The structure used to name UNIX domain sockets is defined
in the file \fI<sys/un.h>.\fP
The definition has also been included in the example for clarity.
.pp
Each program creates a socket with a call to \fIsocket().\fP
These sockets are in the UNIX domain.
Once a name has been decided upon it is attached to a socket by the
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 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
.ft CW
.so udgramsend.c
.ft
.ce 1
Figure 5b\ \ Sending a UNIX domain datagrams
.)z
.pp
Names in the UNIX domain are path names.  Like file path names they may
be either absolute (e.g. ``/dev/imaginary'') or relative (e.g. ``socket'').
Because these names are used to allow processes to rendezvous, relative
path names can pose difficulties and should be used with care.
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
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
for message delivery once a connection is established.  Therefore, in
contrast with the Internet domain, unbound sockets need not be (and are
not) automatically given addresses when they are connected.  
.pp
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,
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.
.b
.sh 1 "Datagrams in the Internet Domain"
.r
.(z
.ft CW
.so dgramread.c
.ft
.ce 1
Figure 6a\ \ Reading Internet domain datagrams
.)z
.pp
The examples in Figure 6a and 6b are very close to the previous example
except that the socket is in the Internet domain.
The structure of Internet domain addresses is defined in the file
\fI<netinet/in.h>\fP.
Internet addresses specify a host address (a 32-bit number)
and a delivery slot, or port, on that
machine.  These ports are managed by the system routines that implement 
a particular protocol.
Unlike UNIX domain names, Internet socket names are not entered into 
the file system and, therefore,
they do not have to be unlinked after the socket has been closed.
When a message must be sent between machines it is sent to
the protocol routine on the destination machine, which interprets the
address to determine to which socket the message should be delivered.
Several different protocols may be active on 
the same machine, but, in general, they will not communicate with one another.
As a result, different protocols are allowed to use the same port numbers.
Thus, implicitly, an Internet address is a triple including a protocol as
well as the port and machine address.
An \fIassociation\fP is a temporary or permanent specification
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 may be transient when using datagram sockets;
the association actually exists during a \fIsend\fP operation.
.(z
.ft CW
.so dgramsend.c
.ft
.ce 1
Figure 6b\ \ Sending an Internet domain datagram
.)z
.pp
The protocol for a socket is chosen when the socket is created.  The 
local machine address for a socket can be any valid network address of the
machine, if it has more than one, or it can be the wildcard value
INADDR_ANY.
The wildcard value is used in the program in Figure 6a.
If a machine has several network addresses, it is likely
that messages sent to any of the addresses should be deliverable to
a socket.  This will be the case if the wildcard value has been chosen.
Note that even if the wildcard value is chosen, a program sending messages
to the named socket must specify a valid network address.  One can be willing
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
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.
.pp
The port number can be thought of as the number of a mailbox, into
which the protocol places one's messages.  Certain daemons, offering
certain advertised services, have reserved
or ``well-known'' port numbers.  These fall in the range
from 1 to 1023.  Higher numbers are available to general users.
Only servers need to ask for a particular number.
The system will assign an unused port number when an address
is bound to a socket.
This may happen when an explicit \fIbind\fP
call is made with a port number of 0, or
when a \fIconnect\fP or \fIsend\fP
is performed on an unbound socket.
Note that port numbers are not automatically reported back to the user.
After calling \fIbind(),\fP asking for port 0, one may call 
\fIgetsockname()\fP to discover what port was actually assigned. 
The routine \fIgetsockname()\fP
will not work for names in the UNIX domain.
.pp
The format of the socket address is specified in part by standards within the
Internet domain.  The specification includes the order of the bytes in
the address.  Because machines differ in the internal representation
they ordinarily use
to represent integers, printing out the port number as returned by 
\fIgetsockname()\fP may result in a misinterpretation.  To
print out the number, it is necessary to use the routine \fIntohs()\fP
(for \fInetwork to host: short\fP) to convert the number from the
network representation to the host's representation.  On some machines,
such as 68000-based machines, this is a null operation.  On others,
such as VAXes, this results in a swapping of bytes.  Another routine
exists to convert a short integer from the host format to the network format,
called \fIhtons()\fP; similar routines exist for long integers.
For further information, refer to the
entry for \fIbyteorder\fP in section 3 of the manual.
.b
.sh 1 "Connections"
.r
.pp
To send data between stream sockets (having communication style SOCK_STREAM),
the sockets must be connected.
Figures 7a and 7b show two programs that create such a connection.
The program in 7a is relatively simple.
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
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
socket is closed (or soon thereafter).  If a process persists 
in sending messages after the connection is closed, a SIGPIPE signal 
is sent to the process by the operating system.  Unless explicit action
is taken to handle the signal (see the manual page for \fIsignal\fP
or \fIsigvec\fP),
the process will terminate and the shell
will print the message ``broken pipe.'' 
.(z
.ft CW
.so streamwrite.c
.ft
.ce 1
Figure 7a\ \ Initiating an Internet domain stream connection
.)z
.(z
.ft CW
.so streamread.c
.ft
.ce 1
Figure 7b\ \ Accepting an Internet domain stream connection
.sp 2
.ft CW
.so strchkread.c
.ft
.ce 1
Figure 7c\ \ Using select() to check for pending connections
.)z
.(z
.so fig8.pic
.sp
.ce 1
Figure 8\ \ Establishing a stream connection