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…
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <signal.h>
int main()
{
int sfd, cfd;
socklen_t len;
char ch, buff[INET_ADDRSTRLEN];
struct sockaddr_in saddr, caddr;
sfd= socket(AF_INET, SOCK_STREAM, 0);
saddr.sin_family=AF_INET;
saddr.sin_addr.s_addr=htonl(INADDR_ANY);
saddr.sin_port=htons(1205);
bind(sfd, (struct sockaddr *)&saddr, sizeof(saddr));
listen(sfd, 5);
signal(SIGCHLD, SIG_IGN);
while(1) {
printf("Server waiting\n");
len=sizeof(caddr);
cfd=accept(sfd, (struct sockaddr *)&caddr, &len);
if( fork() == 0) {
printf("Child Server Created Handling connection with %s\n",
inet_ntop(AF_INET, &caddr.sin_addr, buff, sizeof(buff)));
close(sfd);
if(read(cfd, &ch, 1)<0) perror("read");
while( ch != EOF) {
if((ch>='a' && ch<='z') || (ch>='A' && ch<='Z'))
ch^=0x20;
/* EXORing 6th bit will result in change in case */
if(write(cfd, &ch, 1)<0) perror("write");
if(read(cfd, &ch, 1)<0) perror("read");
}
close(cfd);
return 0;
}
close(cfd);
}
}
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. We added Let’s examine some code from the 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 Now, just receive the signal and ignore it by setting handler to 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). 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. First, from the client side, after the SYN is sent the client enters the Receiving the FIN from the server will result in sending the ACK, and going to the For the server, passive open is the LISTEN state. Receiving a SYN results in sending SYN and ACK, and going to the After the operation completes, the server sends the FIN, and transitions to the Here we can see the “ThreeHandshake” — the exchange of three packets to establish a TCP connection. It is initiated when the client calls To terminate the connection, we need four packets. The client calls 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!
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).
We can also see the parent server process LISTENing and the ESTABLISHED connections, with IPs and ports.
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. signal() man page:#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);
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 use sigaction() instead. sigaction structure in the man pages. 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 using wait() or waitpid() calls, of which waitpid() is preferred.A little science
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.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.TIME_WAIT state. 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. 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. LAST_ACK state. On receiving the ACK, it will terminate the connection and go to the CLOSED state.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. 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.
I have tried the above program, but unfortunately fork is not working. I am not able to connect any client to the server and also i couldnt see any child process logs.please help me.
try to figure out why fork is not working.. because if it fails the code will definitely do anything.. only the parent continue that is just waiting for another incoming connection..
“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.” — You might want to proof read this… The call to accept() is on line 29… Also, you never mentioned what signal() is and why it’s there…
Hello kray this article was published in “Linux for You” magazine and everything is according to the print edition. This electronic edition was later published by them and so has some problems here there.
Thanks