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