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.