ClientServer Symmetry

---

Client/Server Symmetry

From our last example, it’s clear that for every client that performs a connect, a server performs an accept. When communication occurs, for every write, there’s a corresponding read of the communicated data (though the granularity of reads and writes may differ depending upon the specific protocol, more on this in Chapter 6, Advanced Sockets Programming Topics). The relationships shown by this symmetry are important because they illustrate how to build client and server Sockets applications.

Consider the illustration shown in Figure 2.1. This figure depicts the Sockets API calls from Listings 2.1 and 2.2 (a stream sockets example).

Figure 2.1: Client/server socket call symmetry.

The server must create a socket (using the socket call) and then name it (using bind) so that clients can reference it. The listen call makes the server visible and allows it to accept connections. The server then must use the accept call to accept incoming client connections, which are represented by a newly created socket representing the new endpoint.

For a client to connect to the server, it must also create a socket. Additionally, we must define for the socket what we want to connect to. This is defined in the sockaddr_in structure. Then, by using the connect call, we cause the three-way handshake to occur between the client and server, using in this case TCP. Note the relationships between connect and accept. The accept call defines the server’s willingness to communicate, whereas the connect call defines the client’s desire to communicate. For stream connections using TCP, this relationship must always exist.

For the write and read calls, the same symmetry exists. There’s no point in calling the read function if the peer never writes any additional data into the socket.

Closing sockets also illustrates some symmetry, but many details lie beneath the surface. When an application performs a close, it defines intent not to send any additional data through the socket. This case is shown in the server example in Listing 2.1. This first close is known as the active close. The peer recognizes this close and performs one of its own. This is the passive close; it completes the closure of the socket because neither endpoint will send or receive any further data through the socket.

Note 

Another method for closing the socket communicates different intentions to the peer. We’ll discuss the shutdown method in Chapter 4, Advanced Sockets Functions.

---