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,3 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.4 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 |
In the days before voice mail systems!
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.