-----------------------------
Programming UNIX Sockets in C
Frequently Asked Questions
-----------------------------

Part I.  General Information and Concepts
  1:  About this FAQ
  2:  Who is this FAQ for?
  3:  What are Sockets?
  4:  How do Sockets Work?
  5:  Where can I get source code for the book "<book title>"?
  6:  Where can I get more information?

Part II.  Questions regarding both Clients and Servers
  1:  How can I tell when a socket is closed on the other end?
  2:  What's with the second parameter in bind()?
  3:  How do I get the port number for a given service?
  4:  If bind() fails, what should I do with the socket descriptor?
  5:  How do I properly close a socket?
  6:  When should I use shutdown()?
  7:  Please explain the TIME_WAIT state.
  8:  Why does it take so long to detect that the peer died?
  9:  What are the pros/cons of select(), non-blocking I/O and SIGIO?
 10:  Why do I get EPROTO from read()?
 11:  How can I force a socket to send the data in it's buffer?
 12:  Where can a get a library for programming sockets?

Part III.  Writing Client Applications
  1:  How do I convert a string into an internet address?
  2:  How can my client work through a firewall/proxy server?
  3:  Why does connect() succeed even before my server did an accept()?
  4:  Why do I sometimes loose a server's address when using more than
      one server?
  5:  How can I set the timeout for the connect() system call?

Part IV.  Writing Server Applications
  1:  How come I get "address already in use" from bind?
  2:  Why don't my sockets close?
  3:  How can I make my server a daemon?
  4:  How can I listen on more than one port at a time?
  5:  What exactly does SO_REUSEADDR do?
  6:  What exactly does SO_LINGER do?
  7:  What exactly does SO_KEEPALIVE do?
  8:  How can I bind() to a port number < 1024?

Appendix A.  Sample Source Code

-----------------------------------------
Part I.  General Information and Concepts
-----------------------------------------

I.1:  About this FAQ
^^^^^^^^^^^^^^^^^^^^
This FAQ is maintained by Vic Metcalfe (vic@brutus.tlug.org), with lots of
assistance from Andrew Gierth (andrewg@microlise.co.uk).  While I am no
expert, I do have some knowledge of sockets.  I am depending on the true
wizards to fill in the details, and correct my (no doubt) plentiful
mistakes.  The code examples in this FAQ are written to be easy to follow
and understand.  It is up to the reader to make them as efficient as
required.  After reading comp.unix.programmer for a short time, it became
evident that a FAQ was needed.  The most recent version of the FAQ can be
found at:

        http://www.interlog.com/~vic/sock-faq/

I plan to post it periodically to comp.unix.programmer as well, and possibly
put a copy on ftp://rtfm.mit.edu.

Please email me if you would like to correct or clarify an answer.  I
would also like to hear from you if you would like me to add a question
to the list.  I may not be able to answer it, but I can add it in the
hopes that someone else will submit an answer.

Parts of the FAQ that have been taken from email or usenet postings can
be identified by a ">" greater than sign at the left of the text.  All
other work, and the errors in it is mine.

I.2:  Who is this FAQ for?
^^^^^^^^^^^^^^^^^^^^^^^^^^
This FAQ is for C programmers in the Unix environment.  It is not intended
for WinSock programmers, or for Perl, Java, etc.  I have nothing against
Windows or Perl, but I had to limit the scope of the FAQ for the first
draft.  In the future, I would really like to provide examples for Perl,
Java, and maybe others.  For now though I will concentrate on correctness
and completeness for C.

This version of the FAQ will only cover sockets of the AF_INET family,
since this is their most common use.  Coverage of other types of sockets
may be added later.

I.3:  What are Sockets?
^^^^^^^^^^^^^^^^^^^^^^^
Sockets are just like "worm holes" in science fiction.  When things go
into one end, they (should) come out of the other.  Different kinds of
sockets have different properties.  Sockets are either connection-oriented
or connectionless.  Connection-oriented sockets allow for data to flow
back and forth as needed, while connectionless sockets (also known as
datagram sockets) allow only one message at a time to be transmitted,
without an open connection.  There are also different socket families.
The two most common are AF_INET for internet connections, and AF_UNIX for
unix IPC (interprocess communication).  As stated earlier, this FAQ deals
only with AF_INET sockets.

I.4:  How do Sockets Work?
^^^^^^^^^^^^^^^^^^^^^^^^^^
The implementation is left up to the vendor of your particular unix, but
from the point of view of the programmer, connection-oriented sockets work
a lot like files, or pipes.  The most noticeable difference, once you have
your file descriptor is that read() or write() calls may actually read or
write fewer bytes than requested.  If this happens, then you will have to
make a second call for the rest of the data.  There are examples of this
in the source code that accompanies the faq.

I.5:  Where can I get source code for the book "<book title>"?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is a list of the places I know to get source code for network
programming books.  It is very short, so please mail me with any others
you know of.

Title: Unix Network Programming
Author: W. Richard Stevens
Publisher: Prentice Hall, Inc.
ISBN: 0-13-949876-1
URL: http://www.noao.edu/~rstevens

Title: Power Programming with RPC
Author: John Bloomer
Publisher: O'Reilly & Associates, Inc.
ISBN: 0-937175-77-3
URL: ftp://ftp.uu.net/published/oreilly/nutshell/rpc/rpc.tar.Z


I.6:  Where can I get more information?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I keep a copy of the resources I know of on my socks page on the web.  I
don't remember where I got most of these items, but some day I'll check
out their sources, and provide ftp information here.  For now, you can
get them at http://www.interlog.com/~vic/sock-faq.

Included is the TCP/IP faq (which is really geared more to sys-admins
than it is programmers), relevant rfc's and standards, as well as Jim
Frost's socket tutorial.  All of the source from this FAQ is available
there too.  I fantasize about adding my own socket tutorial to the page,
with all kind of nifty interactive Java components, but I'll probably
never get around to doing it.  (On the other hand, you never do know.  I
did manage to put this FAQ together.)

------------------------------------------------------
Part II.  Questions regarding both Clients and Servers
------------------------------------------------------

II.1:  How can I tell when a socket is closed on the other end?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

From Andrew Gierth (andrewg@microlise.co.uk):

> AFAIK:
>
>  If the peer calls close() or exits, without having messed with SO_LINGER,
>  then our calls to read() should return 0. It is less clear what happens
>  to write() calls in this case; I would expect EPIPE, not on the next
>  call, but the one after.
>
>  If the peer reboots, or sets l_onoff = 1, l_linger = 0 and then closes,
>  then we should get ECONNRESET (eventually) from read(), or EPIPE from
>  write().
>
>  If the peer remains unreachable, we should get some other
>  error.
>
>  I don't think that write() can legitimately return 0. read() should
>  return 0 on receipt of a FIN from the peer, and on all following calls.
>
> So yes, you _must_ expect read() to return 0.
>
> As an example, suppose you are receiving a file down a TCP link; you
> might handle the return from read() like this:
>
>   rc = read(sock,buf,sizeof(buf));
>   if (rc > 0)
>   {
>       write(file,buf,rc);
>       /* error checking on file omitted */
>   }
>   else if (rc == 0)
>   {
>       close(file);
>       close(sock);
>       /* file received successfully */
>   }
>   else /* rc < 0 */
>   {
>       /* close file and delete it, since data is not complete
>          report error, or whatever */
>   }

II.2:  What's with the second parameter in bind()?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The man page shows it as "struct sockaddr *my_addr".  The sockaddr struct
though is just a place holder for the structure it really wants.  You have
to pass different structures depending on what kind of socket you have.
For an AF_INET socket, you need the sockaddr_in structure.  It has three
fields of interest:

  sin_family:  Set this to AF_INET.
  sin_port:    The network byte-ordered 16 bit port number
  sin_addr:    The host's ip number.  This is a struct in_addr, which
               contains only one field, s_addr which is a u_long.

II.3:  How do I get the port number for a given service?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use the getservbyname() routine.  This will return a pointer to a servent
structure.  You are interested in the s_port field, which contains the
port number, with correct byte ordering (so you don't need to call htons
on it).  Here is a sample routine:

/* Take a service name, and a service type, and return a port number.  If the
   service name is not found, it tries it as a decimal number.  The number
   returned is byte ordered for the network. */
int atoport(char *service, char *proto) {
  int port;
  long int lport;
  struct servent *serv;
  char *errpos;

  /* First try to read it from /etc/services */
  serv = getservbyname(service, proto);
  if (serv != NULL)
    port = serv->s_port;
  else { /* Not in services, maybe a number? */
    lport = strtol(service,&errpos,0);
    if ( (errpos[0] != 0) || (lport < 1) || (lport > 5000) )
      return -1; /* Invalid port address */
    port = htons(lport);
  }
  return port;
}

II.4:  If bind() fails, what should I do with the socket descriptor?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are exiting, I have been assured by Andrew that all unixes will
close open file descriptors on exit.  If you are not exiting though, you
can just close it with a regular close() call.

II.5:  How do I properly close a socket?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This question is usually asked by people who try close(), because they
have seen that that is what they are supposed to do, and then run netstat
and see that their socket is still active.  Yes, close() is the correct
method.  To read about the TIME_WAIT state, and why it is important,
refer to Part II, question 7.

II.6:  When should I use shutdown()?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From Andrew:
> shutdown() is useful for half-closing a connection; i.e. sending your
> FIN to the peer, before youi have finished receiving data from him.

II.7.  Please explain the TIME_WAIT state.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember that TCP guarantees all data transmitted will be delivered, if at
all possible.  When you close a socket, the server goes into a TIME_WAIT
state, just to be really really sure that all the data has gone through.
When a socket is closed, both sides agree by sending messages to each
other that they will send no more data.  This, it seemed to me was good
enough, and after the handshaking is done, the socket should be closed.
The problem is two-fold.  First, there is no way to be sure that the last
ack was communicated successfully.  Second, there may be "wandering
duplicates" left on the net that must be dealt with if they are delivered.

Andrew Gierth (andrewg@microlise.co.uk) helped to explain the closing
sequence in the following usenet posting:

> Assume that a connection is in ESTABLISHED state, and the client is about
> to do an orderly release. The client's sequence no. is Sc, and the server's
> is Ss. The pipe is empty in both directions.
>
>   Client                                                   Server
>   ======                                                   ======
>   ESTABLISHED                                              ESTABLISHED
>   (client closes)
>   ESTABLISHED                                              ESTABLISHED
>                <CTL=FIN+ACK><SEQ=Sc><ACK=Ss> ------->>
>   FIN_WAIT_1
>                <<-------- <CTL=ACK><SEQ=Ss><ACK=Sc+1>
>   FIN_WAIT_2                                               CLOSE_WAIT
>                <<-------- <CTL=FIN+ACK><SEQ=Ss><ACK=Sc+1>  (server closes)
>                                                            LAST_ACK
>                <CTL=ACK>,<SEQ=Sc+1><ACK=Ss+1> ------->>
>   TIME_WAIT                                                CLOSED
>   (2*msl elapses...)
>   CLOSED
>
> Note: the +1 on the sequence numbers is because the FIN counts as one byte
> of data. (The above diagram is equivalent to fig. 13 from RFC 793).
>
> Now consider what happens if the last of those packets is dropped in the
> network. The client has done with the connection; it has no more data or
> control info to send, and never will have. But the server does not know
> whether the client received all the data correctly; that's what the last
> ACK segment is for. Now the server may or may not *care* whether the
> client got the data, but that is not an issue for TCP; TCP is a reliable
> protocol, and *must* distinguish between an orderly connection _close_
> where all data is transferred, and a connection _abort_ where data may
> or may not have been lost.
>
> So, if that last packet is dropped, the server will retransmit it (it is,
> after all, an unacknowledged segment) and will expect to see a suitable
> ACK segment in reply. If the client went straight to CLOSED, the only
> possible response to that retransmit would be a RST, which would indicate
> to the server that data had been lost, when in fact it had not been.
>
> (Bear in mind that the server's FIN segment may, additionally, contain
> data.)
>
> DISCLAIMER: This is my interpretation of the RFCs (I have read all the
> TCP-related ones I could find), but I have not attempted to examine
> implementation source code or trace actual connections in order to
> verify it. I am satisfied that the logic is correct, though.

The second issue was addressed by Richard Stevens (rstevens@noao.edu,
author of Unix Network Programming).  I have put together quotes from some
of his postings and email which explain this.  I have brought together
paragraphs from different postings, and have made as few changes as
possible.

> If the duration of the T_W state were just to handle TCP's full-duplex
> close, then the time would be much smaller, and it would be some function
> of the current RTO (retransmission timeout), not the MSL (the packet
> lifetime).

> A couple of points about the T_W state.
>
> - The end that sends the first FIN goes into the T_W state, because that
>   is the end that sends the final ACK.  If the other end's FIN is lost, or
>   if the final ACK is lost, having the end that sends the first FIN
>   maintain state about the connection guarantees that it has enough
>   information to retransmit the final ACK.
>
> - Realize that TCP sequence numbers wrap around after 2**32 bytes have been
>   transferred.  Assume a connection between A.1500 (host A, port 1500) and
>   B.2000.  During the connection one segment is lost and
>   retransmitted.  But the segment is not really lost, it is held by
>   some intermediate router and then re-injected into the network.  (This
>   is called a "wandering duplicate".)  But in the time between the
>   packet being lost & retransmitted, and then reappearing, the
>   connection is closed (without any problems) and then another
>   connection is established between the same host, same port (that is,
>   A.1500 and B.2000; this is called another "incarnation" of the
>   connection).  But the sequence numbers chosen for the new incarnation
>   just happen to overlap with the sequence number of the wandering
>   duplicate that is about to reappear.  (This is indeed possible, given
>   the way sequence numbers are chosen for TCP connections.)  Bingo, you
>   are about to deliver the data from the wandering duplicate (the
>   previous incarnation of the connection) to the new incarnation of the
>   connection.  To avoid this, you do not allow the same incarnation of
>   the connection to be reestablished until the T_W state terminates.
>
>   Even the T_W state doesn't complete solve the second problem, given
>   what is called T_W assassination.  RFC 1337 has more details.
>
> - The reason that the duration of the T_W state is 2*MSL is that the
>   maximum amount of time a packet can wander around a network is
>   assumed to be MSL seconds.  The factor of 2 is for the round-trip.
>   The recommended value for MSL is 120 seconds, but Berkeley-derived
>   implementations normally use 30 seconds instead.  This means a T_W
>   delay between 1 and 4 minutes.  Solaris 2.x does indeed use the
>   recommended MSL of 120 seconds.

> A wandering duplicate is a packet that appeared to be lost and was
> retransmitted.  But it wasn't really lost ... some router had problems,
> held on to the packet for a while (order of seconds, could be a minute
> if the TTL is large enough) and then re-injects the packet back into
> the network.  But by the time it reappears, the application that sent
> it originally has already retransmitted the data contained in that packet.

> Because of these potential problems with T_W assassinations, one should
> *not* avoid the T_W state by setting the SO_LINGER option to send an
> RST instead of the normal TCP connection termination (FIN/ACK/FIN/ACK).
> The T_W state is there for a reason; it's your friend and it's there to
> help you :-)

> I have a long discussion of just this topic in my just-released "TCP/IP
> Illustrated, Volume 3".  The T_W state is indeed, one of the most
> misunderstood features of TCP.

> I'm currently rewriting UNP and will include lots more on this topic, as
> it is often confusing and misunderstood.

II.8:  Why does it take so long to detect that the peer died?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

II.9:  What are the pros/cons of select(), non-blocking I/O and SIGIO?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

II.10:  Why do I get EPROTO from read()?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From Steve Rago (sar@plc.com):
> EPROTO means that the protocol encountered an unrecoverable error
> for that endpoint.  EPROTO is one of those catch-all error codes
> used by STREAMS-based drivers when a better code isn't available.

II.11:  How can I force a socket to send the data in it's buffer?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From Richard Stevens (rstevens@noao.edu):
> You can't force it.  Period.  TCP makes up its own mind as to when
> it can send data.  Now, *normally* when you call write() on a TCP
> socket, TCP will indeed send a segment, but there's no guarantee
> and no way to force this.  There are *lots* of reasons why TCP
> will not send a segment: a closed window and the Nagle algorithm
> are two things to come immediately to mind.

<Snipped suggestion from Andrew Gierth to use TCP_NODELAY>

> Setting this only disables one of the many tests, the Nagle algorithm.
> But if the original poster's problem is this, then setting this socket
> option will help.
>
> A quick glance at tcp_output() shows around 11 tests TCP has to make
> as to whether to send a segment or not.

Now from Dr. Charles E. Campbell Jr. <cec@gryphon.gsfc.nasa.gov>:

> As you've surmised, I've never had any problem with disabling Nagle's
> algorithm.  Its basically a buffering method; there's a fixed overhead
> for all packets, no matter how small.  Hence, Nagle's algorithm
> collects small packets together (no more than .2sec delay) and thereby
> reduces the amount of overhead bytes being transferred.  This approach
> works well for rcp, for example: the .2 second delay isn't humanly
> noticeable, and multiple users have their small packets more
> efficiently transferred.  Helps in university settings where most folks
> using the network are using standard tools such as rcp and ftp, and
> programs such as telnet may use it, too.
>
> However, Nagle's algorithm is pure havoc for real-time control and not much
> better for keystroke interactive applications (control-C, anyone?).  It has
> seemed to me that the types of new programs using sockets that people write
> usually do have problems with small packet delays.  One way to bypass
> Nagle's algorithm selectively is to use "out-of-band" messaging, but
> that is limited in its content and has other effects (such as a loss of
> sequentiality) (by the way, out-of-band is often used for that ctrl-C,
> too).

So to sum it all up, if you are having trouble and need to flush the
socket, setting the TCP_NODELAY option will usually solve the problem.
If it doesn't, you will have to use out-of-band messaging.

II.12:  Where can a get a library for programming sockets?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There is the Simple Sockets Library by Charles E. Campbell, Jr. PhD. and
Terry McRoberts.  The file is called ssl.tar.gz, and you can download it
from this faq's home page.  For c++ there is the Socket++ library which is
supposed to be on ftp://ftp.virginia.edu somewhere.  There is also C++
Wrappers which you can get from ftp://ics.uci.edu/gnu/C++_wrappers.tar.gz
and the documentation C++_wrappers.doc.tar.Z.  From
http://www.cs.wustl.edu/~schmidt you should be able to find the ACE toolkit.

I don't have any experience with any of these libraries, so I can't
recomend one over the other.

--------------------------------------
Part III.  Writing Client Applications
--------------------------------------

III.1:  How do I convert a string into an internet address?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are reading a host's address from the command line, you may not
know if you have an aaa.bbb.ccc.ddd style address, or a host.domain.com
style address.  What I do with these, is first try to use it as a
aaa.bbb.ccc.ddd type address, and if that fails, then do a name lookup on
it.  Here is an example:

/* Converts ascii text to in_addr struct.  NULL is returned if the address
   can not be found. */
struct in_addr *atoaddr(char *address) {
  struct hostent *host;
  static struct in_addr saddr;

  /* First try it as aaa.bbb.ccc.ddd. */
  saddr.s_addr = inet_addr(address);
  if (saddr.s_addr != -1) {
    return &saddr;
  }
  host = gethostbyname(address);
  if (host != NULL) {
    return (struct in_addr *) *host->h_addr_list;
  }
  return NULL;
}

III.2:  How can my client work through a firewall/proxy server?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't have a clue.  Can someone answer this?

III.3:  Why does connect() succeed even before my server did an accept()?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

III.4:  Why do I sometimes loose a server's address when using more than
        one server?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From andrewg@microlise.co.uk (Andrew Gierth):

Take a careful look at struct hostent. Notice that almost everything
in it is a pointer? *All* these pointers will refer to statically
allocated data.

For example, if you do:

    struct hostent *host = gethostbyname(hostname);

then (as you should know) a subsequent call to gethostbyname will
overwrite the structure pointed to by 'host'.

But if you do:

    struct hostent myhost;
    struct hostent *hostptr = gethostbyname(hostname);
    if (hostptr) myhost = *host;

to make a copy of the hostent before it gets overwritten, then it *still*
gets clobbered by a subsequent call to gethostbyname, since although
'myhost' won't get overwritten, all the data it is pointing to will be.

You can get round this by doing a proper 'deep copy' of the hostent
structure, but this is tedious. My recommendation would be to extract
the needed fields of the hostent and store them in your own way.

5:  How can I set the timeout for the connect() system call?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From Richard Stevens (rstevens@noao.edu):
> Normally you cannot change this.  Solaris does let you do this, on a
> per-kernel basis with the ndd tcp_ip_abort_cinterval parameter.
>
> The easiest way to shorten the connect time is with an alarm around
> the call to connect().  A harder way is to use select, after setting
> the socket nonblocking.  Also notice that you can only shorten the
> connect time, there's normally no way to lengthen it.

-------------------------------------
Part IV.  Writing Server Applications
-------------------------------------

IV.1:  How come I get "address already in use" from bind?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You get this when the address is already in use.  (Oh, you figured that
much out?)  The most common reason for this is that you have stopped your
server, and then re-started it right away.  The sockets that were used by
the first incarnation of the server are still active.  This is further
explained in Part II, question 7, and Part IV, question 5.

IV.2:  Why don't my sockets close?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When you issue the close() system call, you are closing your interface to
the socket, not the socket itself.  It is up to the kernel to close the
socket.  Sometimes, for really technical reasons, the socket is kept
alive for a few minutes after you close it.  It is normal, for example
for the socket to go into a TIME_WAIT state, on the server side, for a
few minutes.  People have reported ranges from 20 seconds to 4 minutes
to me.  The official standard says that it should be 4 minutes.  On my
Linux system it is about 2 minutes.  This is explained in great detail in
Part II question 7.

IV.3:  How can I make my server a daemon?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are two approaches you can take here.  The first is to use inetd to
do all the hard work for you.  The second is to do all the hard work
yourself.

If you use inetd, you simply use stdin, stdout, or stderr for your
socket.  (These three are all created with dup() from the real socket)
You can use these as you would a socket in your code.  The inetd process
will even close the socket for you when you are done.

If you wish to write your own server, there is a detailed explanation in
Unix Network Programming by Richard Stevens.  I also picked up this
posting from comp.unix.programmer, by Nikhil Nair (nn201@cus.cam.ac.uk).

> I worked all this lot out from the GNU C Library Manual (on-line
> documentation).  Here's some code I wrote - you can adapt it as necessary:
>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <signal.h>
> #include <sys/wait.h>
>
> /* Global variables */
> ...
> volatile sig_atomic_t keep_going = 1; /* controls program termination */
>
>
> /* Function prototypes: */
> ...
> void termination_handler (int signum); /* clean up before termination */
>
>
> int
> main (void)
> {
>  ...
>
>   if (chdir (HOME_DIR))         /* change to directory containing data
>                                    files */
>     {
>       fprintf (stderr, "`%s': ", HOME_DIR);
>       perror (NULL);
>       exit (1);
>     }
>
>   /* Become a daemon: */
>   switch (fork ())
>     {
>     case -1:                    /* can't fork */
>       perror ("fork()");
>       exit (3);
>     case 0:                     /* child, process becomes a daemon: */
>       close (STDIN_FILENO);
>       close (STDOUT_FILENO);
>       close (STDERR_FILENO);
>       if (setsid () == -1)      /* request a new session (job control) */
>         {
>           exit (4);
>         }
>       break;
>     default:                    /* parent returns to calling process: */
>       return 0;
>     }
>
>   /* Establish signal handler to clean up before termination: */
>   if (signal (SIGTERM, termination_handler) == SIG_IGN)
>     signal (SIGTERM, SIG_IGN);
>   signal (SIGINT, SIG_IGN);
>   signal (SIGHUP, SIG_IGN);
>
>   /* Main program loop */
>   while (keep_going)
>     {
>       ...
>     }
>
>   return 0;
> }
>
>
> void
> termination_handler (int signum)
> {
>   keep_going = 0;
>   signal (signum, termination_handler);
> }

IV.4:  How can I listen on more than one port at a time?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The best way to do this is with the select() call.  This tells the kernel
to let you know when a socket is available for use.  You can have one
process do i/o with multiple sockets with this call.  If you want to wait
for a connect on sockets 4, 6 and 10 you might execute the following code
snippet:

--------------------------
  fd_set socklist;

  FD_ZERO(&socklist); /* Always clear the structure first. */
  FD_SET(4, &socklist);
  FD_SET(6, &socklist);
  FD_SET(10, &socklist);
  if (select(11, NULL, &socklist, NULL, NULL) < 0)
    perror("select");
--------------------------
The kernel will notify us as soon as a file descriptor which is less than
11 (the first parameter to select), and is a member of our socklist becomes
available for writing.  See the man page on select for more details.

5:  What exactly does SO_REUSEADDR do?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This socket option tells the kernel that even if this port is busy, go
ahead and reuse it anyway.  It is useful if your server has been shut
down, and then restarted right away while sockets are still active on its
port.  You should be aware that if any unexpected data comes in, it may
confuse your server, but while this is possible, it is not likely.

6:  What exactly does SO_LINGER do?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On some unixes this does nothing.  On others, it instructs the kernel to
abort tcp connections instead of closing them properly.  This can be
dangerous.  If you are not clear on this, see Part II, question 7.

IV.7:  What exactly does SO_KEEPALIVE do?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IV.8:  How can I bind() to a port number < 1024?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-------------------------------
Appendix A.  Sample Source Code
-------------------------------
Andrew has contributed some new samples to demonstrate stdio streams used
with sockets.  He passes on a warning that this technique is not at all
portable to other non-unix operating systems like MS-Windows and OS/2, so
if you think that such a port may ever happen, do not use the technique.

The following is uuencoded.  You need to copy it out to another file, and
run uudecode on it to extract the binary file.  The file is called
examples.tar.gz.  You need to unzip it with the GNU unzip program, and
untar it with the tar program.  These tools are common on unix machines.
If you have copied the encoded text out to a file called examples.uu, you
might type

% uudecode examples.uu
% gunzip examples.tar.gz
% tar xf examples.tar

This will create a directory called socket-faq-examples which contains the
sample code from this faq, plus a sample client and server for both tcp and
udp.

I uuencoded the examples since they are only about 10K this way, and would
have been 25K if I had simply appended them to the file.  Also, I think this
is more convenient since it breaks the files up correctly, and gives them the
expected names.

begin 664 examples.tar.gz
M'XL(`&L:&3$``^P\:W?;QG+Y*OR*#5/;I$Q1)/5P*UJ^514YT:EE^<KR37.2
ME`<$%B*N00`76(AF<]W?WGGL+A9\R$KL^IZF9DXL<!^SLS.S\]H!RRQX*]5.
MY/]M1[[S9WDBR]T+_ZV,XD1^]8D^@W[_<']??"6$>')X0'\'^X?T%S^#O<&!
M$(>#_G!X.'PR/,3>@V'_*]'_5`C<]:E*Y1="?'4;!W>."^6M3#X'0I_W<SH^
MN?KNM3@6.S_X2>+!_T=;*LB#)):I$O!4RN)6%J(*31L\<9OG!8GTTR-OJYB)
MG4AL]S+/"^-2<?,6_3&=]X9I!SIX]#)1@IQ.99+#&EM!(':R)L1UXSR[$H'B
MQTV@-$H;QGG.$BY>`4'XIU^9BN_%3B#<3L\!Y^*P?IKM].J5C[;L\YI)3I]G
M27BT91_7;M;VB@WC/,L7`G4'"QH,7,L"9PD7KS5[<3L]!YR+P_II-;G_T8?I
M_^"G7*/_K\Y.OKTX^W1K?$#_#_>AD_3__I/])_T]M`A/]O>_Z/_/\7F3QN]V
M:B$0KTD&Q&D62N\_-W^\ZVE<B@!&"?A;E3(4<2K45(IJ":#*1)PD0.7"5Q)F
MI(',5=D54@4](<X5S/>FLI`X4$D_F`J>+/(BNRG\V2Q.;[K"3T-H%W$D8B7"
M3);0LE!3Z!/S(L,1YV*>54GH)?%;@C65P%9_DE6P@H*5?LPJ$?BID#,_3L1,
M"E\)X/F_3HI*565/)=5-+RMN8.3U5-+.O+E?BC13L$*LE$QK##7FV._T3:0H
MI!_ZDT1B?R06L.34OY5>6=W<R%+%65J**"M@]2Y.F/F(JEY-S+*B!F#W(QK[
MB8ILY@'8GN<AEF^^?27.]*D]6F67'6-.MB!".^SP!2C<A2AC8CI07&5!EHAY
MK*:P<R&+`K`-IC)X"Y3N>>=BFN6$#0R]C4,$0&@'&0"(`P`9FL6Z#*4)`H7$
M%Q%0O)">#&,DB<@B(@((BR8^``<2S%"RU!38I!AM9`;0?$$D)+*Q[<D*SUCO
M3+Q-L[F83R7.@1[B'X[-J*&0@8QO`4G`6Y:E?R/K)<W6P0M"IFF.RG?`W1!F
MP-<LBG`1E/PR*Q0B7M.&B!U418$H67`PU*$P+'9BL"X!+$JQ\&=9A4Y,1GCR
M3KI>_2S\,-2$J(?&JA1%E:9(4Y4I/^$C4DB@;&K(ANT:L>O3#TL*N""UI+A"
MDHHJSP&1P"^!(,$TTYAIVAGB@S3#O#2O5!<8DOL%B<-D`<1.XE3N1%*&70=4
M21OF"80]@B[Q@&M::,/.E&6J:?SHG)0$MD0V$!!0/0J.-BDAP*D$+@"/80!,
M1&$`4J>>G.5J01.[J`'FTQC.LXI!'\"Z09(9M$!1I3)`^>S]H=V*=?:_=BL_
MS1IWV__A8*]_2/;_$%H'^P/H/>@?#+_8_\_QV=WVQ#:>8]!4&/.CQM+*/21%
M"T>)-?D:XVX,N,BK":A_@A1F8&!3/M`S4-83/$MYC-`**9,%*PVKSZ%O4<0W
M4X7GDPPU]!*@#)KCU`>5G!5OR=:"*OE+'(@+<!W\))*BO<9^=WAE\`X(R"P+
MXP@-$]G>F1^RGX'JD<$B)M3L[#$$Y:$`"BE7&$J0R$3%:5Q.82L\E^SS1!K/
MAXF@"="#233/\0.`GA7B)B85."QPU%"?YGY).B\C'X+]$H0&K@O,`-V/2HP@
M^0$:MT2&-P8Q;1G19B$>R^2$=0M"U2*#FG26E8H,(:A3T-NE-<%:`IB`ZUPY
M=)\FS!R]$R6F2N5'N[OS^;P7HYI-LIL>>`.[_PV\(46",W<1@5W/^R9.@Z0"
M8K>LBIFV/&]W6URC*^23*8D#V(D_TWC4;6J12]?*05>.5CBM9A.R1>?D1WB@
M4EPP+&>*,>Z2=2EB220'D?)%*(-X!E)FP2"-^`N"XK70O47Y`VN8%2`>^FP@
MD5*IB,2X0:``T"1#M-K!%-3*ML:D*_@K^04=\2M`QK$X<`3/24:ND1*):0'3
M6P6*32NT$QQL9S#@5.59.?*@`6CW/`9QA5TM4(#0,.+>T%,4NW!2=C4*)2+(
MI!''XD8J?)HLD$1MBR7CAPN!ITW-XNMC\?+-BQ<=)`83_)B`[#PKQP9;F8`@
M_XJXO`1*PW$P:W91!4R0LTS1/S$2@C>*D%2ALL0B\)!WUNT3#HR%:'/C3_U?
M$)E^1_S][Z+-`)Z*@?OUF3@\.-@[Z`C&UG!/[`Q&B-QY>NLG<<B[T"?+(*3Q
MF2K0$PR-4'CO62"\V?<DKJ=9"D<'?#"_#.(8HH)W[)6E8P2KN0>RA)1#R:FE
MB'U=>ZP%'2J4SXE6#R1(FOT&WC8(%3YHH=*S68[T4/"<%$D*/K`$@=(+Q!*D
M$O]=%1Q]&'R_-YE,>D$0],*0,1$\I5?R_&.`)!4]MPT:5ES<@<"IG0%C:"GX
M4*_.9$5$61+Q24OB,DP:9$2P":V]3*0.;W[GV90:QDG,E'!XB&`,#]GD52DY
M>0('2S`1F=$K38>Z=@=+-GIP_-^6M8)`+Q3=4-"`8+*211>C5=*_:`SJ93!T
M31\I82(,4!W%`L%PI(I*O:>M,6M;7#FJ2HJ=V)*$&0+0<8Y/YO<FPWYT507K
M+[L>F88`E`(%>ZF<XQ$/4.Y1?TF*34`I9QAE.YOLDA;-C&5CXN`0/9OT*,%.
M$88F`F!^F28+#+^0BC4XDO-L1N$!TW4N-V-E0"MW(WH%WB!L>29]$^<0F2F$
MIJ_@&R2DWLLI&>@QG*XQJ-@L[WF&/AB<S*3"(,$'`^KCPDF2S2$V(KW!1F^,
M)N=(O+X\_??QZ^NKLY,+C"CIZ[??7<&W-H95T(0Q-D\IM>9!"3KBI5"Q`*>9
MAL@D(:[D3*(Z9(1Q1(FJK-_O(SI:=\&62?W7IJ;(0$]@:`,@+L!O1?%`]X&3
M+]H0D94R(,A8H2('DSL#>2+UUNKTN)]1DL41DS0N2?1)B!%C7]SZ18S9",)@
MFB7:(Y+D)Y@U0ED&19PK&*(C>9W`X=@*[:;$>90DLH2@4V1`N#YGF5FNTA'`
M!`NY!O$-.H-3D)Z$\:-HS8)01E@E64Q`12>00#L7(-[D`M9Y&:`S'B/:K`2$
MPJZ!]%>D+'EEJ"U0B6=*BQ9(%GJ4<,;)-P)YYO.%B&R@"8LTK@A"+-_%JLL[
M9'JCXB_DWZH8/`KK08!&'-=GIXU-CCQ"!#T&R2Z4UE+8O6TXV3`).(D4(29=
M6*^.M.-A#_28(9MVO:P,=3O>"PU,)YS3L3ZGIJF0P%5C&0;&KKR&LYIK92AK
M2QNG0(J9X0.3R@@>"8=UP2=Q&K8[=)+9!L%Q*:5J:_O7$0\US*[H`SWC_Y)9
M9$T'V0[]I0>*<QSYLQBTTK$X>3X^?WEVO=RO3;]Q9MRNING#TY.TSU^>?/OM
MU?CDY8\=VO`R+=&KH8>V7J_;9%_?&K>5F4_1NV$CEU/BK-WBGI;VAU"`VF!7
MV:PUP,BBZ:I9F0!\5ME-GJ#";UFN5A#I@I)[,49%A]B_OAQ?G;UY?8;;[HJ'
M-<^[S$1-_[J]PX1!W(B3J^#;2R+:Y*D+U7)U'7$0NB$-'<*5I>ZBF\,5<7SL
MJGFS#D-;@_]!AQS*/U>R@C`I1VT4Q;=NU@BU'HB[U0AW?,`7T'IU)OQ*97A$
M4/07<+S^2J>15`-!`IV:R/;*,75H(]8=8C_`K/N:C:"\\+^:4DR:NQ>@0WX6
M4T;5QX@CT6G>+`BJ`I-\\#Q),D[Y8N1.NJ"H<L76S"5*"7X!PB@SZS^`+U1@
MJD\&%=E^P&C=,CWCNQNLH1="8#@%9^<OKZ]<?&N184JT[&X_*#K\<06(/^\]
M\U<_..H1*([^8;M!4[=_B9P&.9SDHL:(+3/#';!)7[L8UM'9#Y(=SX;/U>NM
M$+*QE>,FKL1\H[8Y`*Y!N8`VTQ4AG)+-9,\M7]@$A-Y&`XRKR70D1[/UE1,[
M#[P\[A`=.K:K90[G,)XD'SB$[',V<']OGYAXFW=/[CTYET+OR>S'\D:8PP:N
M2Q,3&*+B%%0(`UA#O#MX_P'NNQ):_ZOCH.69)DS"W;KC5@V'$SN1OWB#C($X
MTSKJYE[+]?_9F[P!#9GJVX)=M+8]-U>CZ<DI'7#.=SEC0&X9J6@8(%GG;'3(
M+8G![;!>!\.E0)+R0>@Y,F;PN!HQU5<HTC(.DRI\[>3SE8#VU'"CKJNVE//!
M(6SSN:/&B@^4#<$#3B=86E#RQD<_CBX_B7HZ/V4.JTD?69ZOI`QTJ&W<QV[-
M=#?!M,Y'U/9QK6%TDR4FU64WW%)!WK+N36,^\:=S]^PJ=&;S*#>+$.5`#A6!
M[P`>>-%M+5'_2-@$CSX.B$#OY]1HU#H9I*5=NW4FN>*PQR#!(YKIA_NC82(R
MXU%N1N4SN;AMF]?:[.3B'\SMV401$G.-3UL[LS!&DZ1UJLE`MY+B`:53:.T'
M(>Z^2\FC%.C=)OGL=#G?1FAU[A8\)GZM5(_-<YNE^QXNY:I366<9:\`-VVPL
ML^ZNC7.#@TO:%5$P,@9G_!*5UCPN@5PS';73Q4J84RR(3BP=<<T2?;Z-\WR?
MW?U67WGE)#00;ZIX"H>Y"&'*]ZX0F94+L`LS"M"ZVKGD"-GD;O!0D':O"B=V
MIDQ-Z"NP!1G=LQ99=3-U5*V-@?'KF!8SWZ+0J-%)%?&6QZ@YJU3IJ)=;,/U1
MTE00D;[1@.@F4",)&7G10-]ZZ%,7$EYB:3;;>0",T#&H$!(T1^PX:VH"ZP5`
ME.U\8LG#A\9+/;9>JB.$SFCTNIJBYFP!6QWD'Q^O=%;12JO#9\+[;D93VN4>
MG,;ER-XW.4U,1M-;^&DYPQ*9L,E;AM]@+F@"]1M87&*:9YG%!':5QS3V3AYS
MFNE8[_L.+B.HM5QF"/=FLQZ^@<]Z'S6C:0>&I6ZOPVG;?">K'4\':RB,KZ%=
M':ZAB.F&,):W6&A%U1)8O($+(G_`">(+-X5)KX1])4`$JV-:H*A:.B1F__A=
M/*MFQ#K1(FQ:)@_K(D-:P^HE<T^B#3EFP]GC#ZO"Y"`1?823@8;CI!*!K;-U
M%#9BYCR1M`4(X@+8!:.;R/1&3=E/!YRZG#I\!_)*LHN0S+4JG3%,6H=Q&?A%
M*,.ON9R,8JF)!*=V[N/M3E/"\8IMC?8"^JP3;1Q8'VDKTUC",V8!U*+.4'2A
M$1CVDHJH;$_BE\K1?MB\-)1OW4;U$:FG0.@\L(:CH4@;NN^AG=$5`T>N77W:
MB!I)]$P-5HEU8U@90.33?*U2^2XG^PMNC(V#EJ[O2H[V)`@:"`U,QIMK@IDG
MOL+D(MT(8-B25N_L7>-[BR`</8>@5A_@<5TAPG+C8`_.<)UC62(J7DX>U\0?
M;1CV^+'I<1`QC>_UR65W!#%\9I3#^N5('HS6J.&M/^VD'/`TVQ.LXPM!%T^9
MU0&ZMA&%WW-Y8,ZD$];5YY)%*5:L\Q?:`:0UFZ<BKY9/A:/V`2$FL>./C)L:
MF8^/*N#\HD^$+MS[+X7?O_]S9_W7]-.L\<'Z[R=<_S48]O>&6`L^..CO/?E2
M__4Y/E_JO[[4?WW&^J\(B!L)NEKZ_NS%J_'W8^\;:$'OK-%8EXH]Y8O?WO29
MVZ;".%MI2N+)<AL:N*6V1;F+"89RM5G;OT8[N?'-)B`++-9L2Z7"W,8N,+[1
MGL00_)0K8\,E1/TB]W<1`#;?MXQL=,\RH=%'WRJ//C+;.?H=,?WH]\>*H]_A
MA(]^@XL";O4W$M1#]`?P.];:?SQ=NY]N#;'??_+D8*/]AT]?UW\?#(<'?>P%
M9^`K<?#I4-C\^7]N_S?SOYRI?'Q;1(N/?@W@`_[?X?"`_;^#X?YP;XCU_X?[
M_2_O?W^6#\2)YIT:6R^5B3*7_EOQ^N+Z%4>&],Y<_9(5_(FCA7%.(*H4:-X!
ME'D;#GT,O,C'>!.B3BK'XB)&DBWQV)3+88H-[[TDANX9^U6KE>*5BA.J%/^`
M![!J[=?9:FCP"QI'83*G=\QUL;Y\JU^_ZJ$'=WU^<7;YYAHKZ<`8A&5'R,3/
M,:,?RB1&JO#^7Y]_=_+BZL(DO^R]M+T":%POVB6Q>)&*)OKD<I]=/N\Q/'++
MC9.&T38X?6HQHA2K9H<!PI6,^`H5E]G!+B&P[PGFC<?56GXX-N/;S\]?G(GM
M*->6.YY)&-_Q]#T+&CNPK#_A6[F_C.JV[5SQM1#?F[='(\Y0_.IM^8E?S-H&
MT,C;@J%8"4$VF*PT`-OKBBC'3AY-]T=;F/'X&D9WO"V`0[<6:(-;3X$2S_#2
M8LO)!O7A*X3\!/WQL<D%Y&R7"=3VS@XM?2P>_9P^ZO#LY8X".[:V&<='/_<?
MX6QSC_6@Q-LJ)(`%JM?!)O%4[&'5.325><I;:T'TNK=_</CDG_^EU<$<TM[R
M9K:WM^$<)9BFDJ%E&^WNO;=%=0:41`.B[_U".,)_L(K3`%C64,U;$"J+VXSH
MEKGI?T\#6+RYYHZNXV<S>HV6LS[T"%Z,\[Z=$7B6/9.Y-?-TQA1X..#<H!['
M,FFD="0D>KPZ4\0SK32B0IA++NIC?PL0&.MACD"Z#E<T`W>TU^O=)9FW/A5[
MPU_[';6Z:M_Z(&XSDZ^_+35_B6,$^-;OV"F`2YN^4P.0"<)&&MJJ+VXCXB6[
MG+0EW8ZC\T6;LO'"%94=,0#A^+E8N?MU(,&!H*JER^>4S$*BOL%W4X^$M<'.
MNZ#\CRX$@*&/N.N1*1BG>QQ?OT*#;\#"PQ%=PAJJ8WQ*#BZHP<"XQ/!\^],O
MALH;R@-TKE?[QO6W(N!G9F$1Y>[7N?FZCG6D>V8H&\?B8/NP/^)T\8&8Q6F%
M0J:KN">2WY*1*5T9FGHXNJ2'7<"1'%I%M'1#+UKG:5E%41S0*Z0PO)K!0\DL
MV:+2KF''Y&`]G;"^*;*WSJG@VA%WV:_I,COWBU)2T/602R*)CH-?=#$$_$$>
MMCJ;D3OUL1"9X(A'#\I'>$BP6L6\N$.:2$.]`U^J/3(FG)#E$UXCSS<]`,AN
M@RBW<RR&(_/U%E7J<&2AVE?4Z\(LEH_U10'.C7U7G+]Z=75Y?3F^/GWE7!+0
MS*<FL0T$6:UTY2T.5K:(Y5*^>2NJL+@4P4HQ@.:%<R_NWO47P5H$G#O^C1CP
M.POV1H@O\>"P2']6U@A%N:;-6&5CS*EHM%J%K2"8KXX)JYS&=6#@G`::92.J
M$C(F`U0LW96(X;#/3%TB".VQ8>L+U*ITS$C3P,1-\MAZ8V]BEEPB;1W<4[-*
MH/DT(S]D+O]DT=%O^-#[/:3O+D[^X_O+U]<O3R[.7IR]=/:)[S-D"9+4RIEK
M(.:XB];W9R\NQ8/2FF?6J1MV6\,&J/0V>T9JU.B`+IDK*ECQQ5^NGO]HC1:]
M'X,_]J!OD7!STOI8YA)RU0E+%_@3!8UZ7591.SN6YFMV16O3KD@3/WZ,1+YC
M6TVRTY5[EMY)MS^_.;]NW9]>Y'HB2*V`@8MHH6HA_S`(?B^"R*1/"+WE#Y)C
MH41<YEB03^@TS*G!M9=]M(W_Z&CIC_>Y(_XW@=='_PK`W?'_H+^_US?Q_][!
M`?[^S^%P./@2_W^.#QS3FM'@K>)##.Z\N3?F]Y=TM/X1H?G]DO-UN+XN7XZ>
ML;>]72>2X0M^/U$*?];#OOY\>OGFY;6.4=ATL?."W@DZG)GXMS?/GY]=]7#R
ME0[(N;X6$Q4\D<L;8.]\\XV_'%2_?%#2U!^X9L7'V*C4I0>D[<!^QA%>>?$U
M_G:6)HMM<W^>2[QZQU]_01B@4CT;#:TDR"%`R>*0<MR1++KZ'2W,5WOF7=@;
M3-(7=7".99ZFAI2GC9HC;:5)(B-%GA/5#+@U4;^BZ7&&HWOO;4'GEO6W;$%(
M5^283+<0T6YIJ\=^%E92+!5#F9@:(5$!E!O0-LJM$.+(B8Z-Z^9.P#)&;ZO>
M$CBTB+!)$)C8Y+UKD%UTO>7%=0&%%37R\E9EC9T_5]A4UA`UDKU[B)K.FGU`
MVG@V!*I)I:_\_`1<C9)^I8@+XV$RS"&,FD+5O$$Q`?:]9<L)QXV$.4W_JW)6
M5W]\I*!]?K'1?KT6G%/SNC-G0-DC:E;?Z9'7UF&B-R/3.(P+OG+SDY'`**'C
MAF3H4^FX9&@=K3A"2'CQ//>1#RX,4.\]O=1%%N+O0<$3;`7Y(B._2CA32&^Z
M<M?<Z6*IK_L*)?CW#^P<?",QE3LL%#+L:!AF7`U@_<!B(K`FVB\6#9#@%>-;
M&GC33>-+`[<>WH"\=CQ.>9EQ56KB_T][U];4QI&%G\VO&&<W"#E"`2%P"HRS
M&&1"A8@MA,U#BJ*&T8!4NA%=K")5_N_;Y]:7N6B00X@WZ7X!23W=/7T]Y^MS
MOB/L8V*L"AQ=7:*L(G@6FC6,:&&7H/&E8#4H46TE7&&@M%#QUAE0[Z&>`%:3
M`CJHBI0H_H!5Q*!YL$4"03BU'WIBGX5P^_9.3T:7S2K1UV80WG4C4%!NV)T9
MBD7_.2JFT[WKK*O#)]:N!Q-FSF,1'FSFAG$X7A_=3Y'TA"VP@3Q+%46EA'VT
M$(#6LO$OGOI\2T\:_B\'IZ=J8PO6ZJ\`RRF[/Y\>G!\W\.?:#_S["D%!CKZ;
MW(YH-X'ADQT(MY#9[>3W8-^M>,_^&0=\/[@^.7O_[CVO2\$2`7]NC^[!6(SL
MZ%]1[OV@-"^5@Q^5IOU-L*L4<ZUN3^;=J=+ZUB`?("ZR42'Y66E:VJ5-Q*GW
M%.JEK]64[<&^0MEOK.SF+73_O`*HY07I:]H9EQIJ.>"NO'A!DG*Z]:VSZU;S
M"(K:13?=PX_J?^N!5:Q7`R'XJ2QX>F:;W/>PM$S5PD_JB350],AKE+N@0@4E
M=D3`_#[+!0O;-6MS%EAT82"@0+`&CE7J3``K\?7?9H"MB)L43<FQ??3!0AT&
MS<;%Y=GYS\QP`#-T-@1+$37WF4TGGEY##60084TPJ58FF?M<BN5$9]^S$$=V
M"V)7\.99LV%T^PP^EA3-B5WH"^$YX>-I$`\`2F8(*\5H\NO&52:P]=GI?@)K
MTP-@,28%:\EN+-.XB!<:];U\8ELN]2SX^Z&LXO(UJ:U1TQXZXT%V)=BCG-\9
M#V/;8HL9:.&2'"%CH2+6KYH1:=AFD!E'$60T:[Q><AUED#<$3<!?(:.A(=*"
MLV[3*A2LW9SX%@F^D_L8$#JPD+<D@.#_;Y"':,<@C#:YT)K[.F5\I&P+&]H+
MTTPGAPBJF+^)KZS4USRI<HB;DM-&<QSA08#>'A.^,)IHGL[1>(#3<E=&'\E!
MU&>Y9/@>=9VCQOOK5N/\X\EA@VS]ANO#&7B1D)4P<<;>HJNN49C4E(0EQ:4@
M?JPSHWHW&?4_Q<Z\`V%'DV@X&P:8(L]0;Y!])Y*[!(3;V_I&)`'E9]Q^O)J$
MO*_:TQ37:/IK'(:,[]4A>:VGHG6=)9N$JA?$.US6]NSF08=+I@[M2)6@M%LJ
MFV-PU-/V_H8XR>Q)H1KT3#?!U$3!NK[[3M^)HNHE9Q2V0B\2ZVV@(*F$IYJS
MWN&OF9TZ:P:SE-ZR\05T`S,>>.GLO[#VG!:\U?(^]HWCIT=(XSB.=2W6&ACU
M_DE(XR/POS]L!5X4_V%CB^Q_ZK7-C<W7B/]MOO;VW\^2;/ROX^)["TUEX[Y2
M)Q>9T.8:QV8AA4O#7[G6H478QMZ2FLC>HP^(O.,A^++S8>\I!*B]Y:7B/3S[
ME70)D^&OGIT^_=DI?_]OGETT6D]2!^S_._G[?_!Z>SMA_[N]X>T_GR===,)A
M#V&G@Z&2D>?!<3<>3SO!FX/FT7GC\O@_@VXT'BG%,ZY&H^JL]U;8"($*GB<,
M<<PS!=Z$S#3`8&BH34O5;H(>N#?A1//A&,\B0D39ZV0%[&6T)BD4\]H.2BQ<
MM%(`U]3S\&$79+A_6QEE0ZN2/P[R)FX&O\*?&G[8JE:K5RL0TR!DW6(`'C>@
MXN2<=40=,[AG5T?`]!Z"4_`U9:2LLA+VE9I/G`9=XJ>W#9@`9@8V4""M^7A>
MK];X.8;I(.Y!>*,$='1JA6X]"<+^9"0M5)MVHFG(8PDM(ZY%`N$F"0,+](O^
MV(TRB>RSUK\5PNA)YEB!_+>EQ#V2_]3ZK\->H/YN^OO?9TG>_\_[__W%_.\+
M+0<LBX`BTU7-HR"VJ6)OJE0`8W+JT)QJUE)M1XJ6VSE,3VR4:T6>0]P&X`;;
M0MA]:(Y#A!DU95S4@8-!\^/J0"Z=.+\<$Z..CT`^,U`UL+C3$%W++\90.8^&
M%B&52Y"I[3N3+G_8T[6KA*&G,4ZU3#R7H>X*;D,U\=J+N+J,-Q\J:JS8F7L-
M]8F0<#'A;U$PO(!,^3F'Q7JAYX`F2A(.*PI]%TA3Q'U!G@_$3!^FU<856S#0
M469/+,:G'0)!8U0.K2>[<K"4.VBW38P<PW]AW!&MEW9()1_5+>Y8Y+33\`46
M]J"AJI"L;PY/SUJ-H[<R@&3$A\:L%D>%-^'[^E*._">A&)^DC@+YK[ZSL:WE
MO^V-&LI_6SM>_GN.Y.4_+__]?\A_!8P0.5AU#@/$/.PFT.L(V4)%SN1P("0%
M,?]42R9.C#U!UNUB&:LZ,9J.^^N1L!WQ$6N*,)Q,4#G9U8+=OA(&^VJ0AQ4=
M^D#U_0.'^;B)(6Y&\#O8_,3$#8G(MNJ"ZZC/2#EV!](XP!G_K^XM<&R\:QVQ
MM'O?U7QB$!1F-K'Y\8(U]3/8V:DV;:VM4H9*<-D\^^F@><S4X&6\3=L3UH//
M7R"+9XC=.0*Z2W"FV:JDD"S26]4#1,P+_+R58-1OJ[\IN;[V"+E>1.R%(OTE
MKKJ4Y"UFG6/7+&(Z*I+&@8=X@2C>O<.@A<`.NZK>JSH)KP?AA"0K_GS;#^\F
M),LYP\\_2]",?9DW>U0N==I:Z^3X\/0(O*:@]U:I^W"XR1`A58IZX/KDN/G8
M4G#2K*2(?UU/N26(?S\,,2@)DNZSCYOJ;1%4;6TD@_F?%V2"#L719X@"9=7L
M`71#[*YHF=@)&?V;R[B/2Y9]:JW(F8X#5;X>\CV8^D(0+XQIR;H`LM<EA/U`
M;K?0Q"XG!H`1\(UMB<W+]\&TSZG0<,X9OKA]Q]#7O$$RHXG496D<69GV52]A
M!V668?/<)W\V1'J?S;LT(#3IC3HFK5YO2X#1^_YLHIDL+17+T<@"R]774K#,
M\'(/E),,_@L4*M&5ODZ=*$O^MV*J/TD=!?+_ZUJ]IN7_#>""`_S7R__/DKS\
M[^7_YY?_EV5ARQ+C'<ZTA3I$!H=;'E];AJ.:&ZMT.<$7Z=]GXC^GU0<*;Q?V
M>YH"G2(MIJU*:!^NL.S`L4^(QL!X]]L!MDQT"#7$G]KX1#/EVH;4SFV35[UK
M.,#@X@1'4IQQ:&G(\<:'$;HM6$[/)>W(I(M!$EJJ,IY+7'(=^S+AJBX:";PS
M<8O@DZ>:F%GZ@?,`O[@3^@*S_Q>D1:=+R9$A)R`&A0%-!":#NJQFZ1BKF/L#
MFYXBC1%LB!3;`2;[73QFFW1R9[;(*.H%NH8^8G4C=!R4832FKBZZ4[`BG*B%
MV;V7+RIBD&O"Z.87985?29ASIR/(DM%W?EF)<+SZ1210$,T6OL@F^7AQPW"2
MH=U6KGZ4HU;`'07'$T'_>/H-6J(=0BG"N8FV4*QW$%,''(@4WM'2-[9R]8U$
MD!&MG7"S\.=%S7I,")*<@"-."VNY+32+WUC"\TMA0-Z*B5BG/B6%^V1;OM6!
M#</$4N&94=1GB091T#WS57E14!([%)!IM:8<62ZV'@7,&H*ZH+K5V9;UCC0)
M8"EBX#)<0S=X+@J?$GGUD:YD]E+>I<PY2QSFEIF[TFI!9HF13L,\2271N3&2
MF'`4;Q$9]PT?A3D)4F%E*(<=58:^H=LSUE'S8LI8/R^*&N-D=,(K.@T.A\P(
MK_=WV%]!:.F/E(3G!`-+O8><C.8]Z)LR7T"A_I+W'M;/A2$>G=R.)X>98461
M6O0Q[K:T*$Y+UI1LQ1B6^+>9G$?FP`#W8Z;P2@0M#7'I3$QT62LN1S)V+/D"
M.6AD$"5E#BH%!,+Q#-T0E9B-WI(@%$6=[C2FY5&UCD;P>9^.A*''K&C=+=8B
MQW'%2C+[4R9Q8@:C%[#JT,!=YECOHCZ]Z&`,ARYUZ%!D%^ZVJBU/,`O:?F(H
M2:-7`A>ZQD>?8#N7-V4YB!_`3_A^^:\GTV75KE-/-JHG8^I(Q7E(HGGXY;[;
MG+S-_!@"DP.@,A^#^7#"<?UE/FA)_;<?#*>C3I\KL6_G#PG0H<-=G5-=.!5,
MMJ\$'/D'I!S\YSGO?W>VMNL:_]G<0OO?6MW;_SY+\OB/QW_^5OC/X\&>/P3L
MT(4PG(P+L(<").<@'1@=EQQ+6_IRH2A94-`7H3\P]*I3,/=/HSDQ5;#9^MQ&
M)'".`,'OC^9A$YQ*P*[(/MN?#NFYD'O61(]7T^A+T4VO05\,Q^9"J,5!2=33
M)DQM%DR27QHZS=LPR9*PQN95Y4M0C3?YZGKB+I6"=4ZJC[](_;-5\/,80Z%/
MK3,#57)8*#=*?P1FXQ0BJN<1K2'6T=]A=F1FZ4Z[85])P$97A[%$,&]B-D!;
MUS%3$WD159.@&=P0#("G^@^U)B!-I+,!-WW@962E2^52&UG4@U-N/J+#9Z8#
M68.5\#WZR@S"GB:85'MX1`SAK'.I8V-,,!KX2E8I%)T$$;4P`+K%)B=^51H]
M/5#[C5H"$O9O^##GOH%"1'_074H]<8?(M:X>^]K>LKJ@`"8T>:,^PN$'YQ9@
M&=P-T/+[$398%N_7I=YKK.*9T)/,9BV`4+)546[)8S$)K4/;.N;2B`3;`&Q:
MU@O'2$IE'1N"5O"E>Z$BO4"5II/**-/TV8(+EM:H<W3J?*W:[00[O""W>C_9
M.E,F?V,48\XA)=.1R?$\X4B6MK#:K"0&V!B^A65_B'EA984ZOK+TC_@ZVZ7*
M-'-_$T0)M7R$>OCT)@U>VTFD`9S(P6XB`]LL'`!+J,F=>,X!X8`WZ=XW!B#R
MEM2S]EN2!89'$GSRR2>??/+))Y]\\LDGGWSRR2>??/+))Y]\\LDGGWSRR2>?
5?/+))Y]\\LFGOU?Z'W947[``R```
`
end