Welcome to another dose of socket programming! Till now, we’ve created servers that are capable of creating connections with multiple clients [Part 1 & Part 2], but the problem is that the server will communicate with only one client at any point in time. This is because there is only one socket descriptor, cfd, created to communicate with a client — and all connections will wait on the same descriptor. Now, let’s use the fork() system call to fork a copy of the server for each client.

Here is the code included from the previous article. This time it is for IPv4…

Let’s see what we’ve done here. At line 23, after getting the socket descriptor cfd from the call to accept, we forked the server. The child process (where pid==0) closes the listening descriptor with close(sfd), does the work the server is intended to do, and when finished, closes the descriptor and returns (see lines 27-39).

The server, on the other hand, where pid>0, just closes the cfd (line 39), and is again ready to accept more connections. Thus, for each incoming connection, a new server process will be created.

Another method of doing this is using threads, but we’re not getting into that right now.

Now, compile, run and see the server running and handling multiple clients. See Figure 1 — I’m running the server on a network now (;) though these clients are VirtualBox running VMs with Backtrack (192.168.1.19) and Arch (192.168.1.4), and Android phone running ConnectBot to create a TCP connection.

Figure 1: Server screen

Also run netstat -a | grep 1205 to check for current network connections; I’ve greped 1205, our port, to show only connections to our server (see Figure 2).

Figure 2: Output of netstat

We can also see the parent server process LISTENing and the ESTABLISHED connections, with IPs and ports.

We added signal(SIGCHLD, SIG_IGN) to the code to prevent child processes going into a zombie state. A child process, when it finishes (a clean termination or killed by some signal), returns the exit status to its parent process, which is notified by the SIGCHLD signal sent by the system. If the parent doesn’t handle this signal, the child process still uses some memory, and remains in a zombie state. If the parent finishes before the child, or doesn’t collect the status and terminates, the status will be provided to the parent of all processes, i.e., init with pid 1.

Let’s examine some code from the signal() man page:

signal() sets the disposition of the signal signum to handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined function (a “signal handler”). It also indicates that the behaviour of signal() differs among different Linux and UNIX versions, and tells us to usesigaction() instead.

The problem is whether the blocked system call, after running the signal handler, will be restarted or not. We can look at this later, when we write our own signal handler — or just go check the sigaction structure in the man pages.

Now, just receive the signal and ignore it by setting handler to SIG_IGN. This will not let the child enter a zombie state. What if the parent finishes before the child (though not the case here, because the server is in an infinite loop)? In that case, the parent can wait for the child usingwait() or waitpid() calls, of which waitpid() is preferred.

These system calls wait for a state change in the child, such as the child being terminated or stopped by a signal, or resumed by a signal (check the man pages).

A little science

Now, before moving further, let’s talk about TCP here since better code requires a sound understanding of the basics.

In Figure 3, the rectangles represent the states, and the edges, the transitions.

Figure 3: TCP state diagram

We need to visualise the server and client in the diagram. Two edges come out of the CLOSED state; one is Active Open. This transition occurs when a client sends a SYN packet to the server, and the system is initiating the connection. Another is Passive Open, where the server enters the listen state and waits for connections.

First, from the client side, after the SYN is sent the client enters the SYN_SENT state. Now, after receiving the SYN from the server and sending SYN and ACK, it transitions to ESTABLISHED. From the ESTABLISHED state (where communication takes place), sending a FIN will initiate an Active Close to terminate the connection, and enter the FIN_WAIT_1 state. Receiving ACK will move it to the FIN_WAIT_2 state.

Receiving the FIN from the server will result in sending the ACK, and going to the TIME_WAITstate. In this state, the system waits for twice the MSL (maximum segment lifetime); the recommended value in RFC 1337 is 120 seconds, Linux implements 60 seconds. This state helps reliable termination ofconnections in case of lost packets, and allows old duplicate segments to expire in the network. Finally, it goes to the CLOSED state.

For the server, passive open is the LISTEN state. Receiving a SYN results in sending SYN and ACK, and going to the SYN_RCVD state. Receiving an ACK will take the server to the ESTABLISHED state for data communication. Then, receiving a FIN will result in sending an ACK, and will initiate the passive close and it going to the CLOSE_WAIT state.

After the operation completes, the server sends the FIN, and transitions to the LAST_ACK state. On receiving the ACK, it will terminate the connection and go to the CLOSED state.

Here we can see the “ThreeHandshake” — the exchange of three packets to establish a TCP connection. It is initiated when the client calls connect(). Packet 1 is SYN x from client to server; Packet 2 is ACK x+1 and SYN y from server to client; and Packet 3 is ACK y+1 from client to server. Here, x is the sequence number from the client, and y the sequence number from the server.

To terminate the connection, we need four packets. The client calls close() to initiate termination: Packet 1 is FIN m from client to server; and Packet 2 is ACK m+1 from server to client. Now, the server finishes the operation, and then calls close() and sends its FIN n. The client sends ACK n+1 to terminate the connection.

Here’s where I close the connection, even though it was short this time! Next month, I’ll be back with a new connection to socket programming… you can now ACK my FIN!