gawkinet: Making Connections

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