gawkinet: Making Connections

 
 1.4 Making TCP/IP Connections (And Some Terminology)
 ====================================================
 
 Two terms come up repeatedly when discussing networking: "client" and
 "server".  For now, we'll discuss these terms at the "connection level",
 when first establishing connections between two processes on different
 systems over a network.  (Once the connection is established, the higher
 level, or "application level" protocols, such as HTTP or FTP, determine
 who is the client and who is the server.  Often, it turns out that the
 client and server are the same in both roles.)
 
    The "server" is the system providing the service, such as the web
 server or email server.  It is the "host" (system) which is _connected
 to_ in a transaction.  For this to work though, the server must be
 expecting connections.  Much as there has to be someone at the office
 building to answer the phone(1), the server process (usually) has to be
 started first and be waiting for a connection.
 
    The "client" is the system requesting the service.  It is the system
 _initiating the connection_ in a transaction.  (Just as when you pick up
 the phone to call an office or store.)
 
    In the TCP/IP framework, each end of a connection is represented by a
 pair of (ADDRESS, PORT) pairs.  For the duration of the connection, the
 ports in use at each end are unique, and cannot be used simultaneously
 by other processes on the same system.  (Only after closing a connection
 can a new one be built up on the same port.  This is contrary to the
 usual behavior of fully developed web servers which have to avoid
 situations in which they are not reachable.  We have to pay this price
 in order to enjoy the benefits of a simple communication paradigm in
 'gawk'.)
 
    Furthermore, once the connection is established, communications are
 "synchronous".(2)  I.e., each end waits on the other to finish
 transmitting, before replying.  This is much like two people in a phone
 conversation.  While both could talk simultaneously, doing so usually
 doesn't work too well.
 
    In the case of TCP, the synchronicity is enforced by the protocol
 when sending data.  Data writes "block" until the data have been
 received on the other end.  For both TCP and UDP, data reads block until
 there is incoming data waiting to be read.  This is summarized in the
 following table, where an "X" indicates that the given action blocks.
 
 TCP        X       X
 UDP        X
 
    ---------- Footnotes ----------
 
    (1) In the days before voice mail systems!
 
    (2) For the technically savvy, data reads block--if there's no
 incoming data, the program is made to wait until there is, instead of
 receiving a "there's no data" error return.