Hello! I got few questions about the Linux kernel source code for implementing the TCP/IP.

I just want to understand how the tcp/ip handle a incoming connection request from a remote client. As far as I know, after a connection request from a remote client completes the TCP 3-way handshake with the local server (in Established state). It would become an open request and this open request will be placed in the accept queue. At this point a new child socket is created and pointed to by the open request. And each time an "userspace application" (http, ftp..etc) process executes the "accept()" system call, the first open request in the accept queue is removed and the socket which is pointed to by this open request is returned.

I tried to track the source code of the Linux kernel. My questions are:

1. After a connection request from a client complete the TCP 3-way handshake(in Established state), does the function "tcp_acceptq_queue" in "tcp.h" must be called? Does this function handle the task which puts a new open request into accept queue ?.

2. Each time the Web server process executes the accept() system call, Does the function "tcp_accept" in "tcp.c" must be called. Does this function handle the task which removes the first open request in the accept queue and return the socket which is pointed to by the open request?


Is there anything which I describe above correct or not? Or there is any reference regarding this matter? Please tell me! Thank you very much!

p.s. My Linux Kernel Version is 2.4.25

I can't really talk about what goes on at the kernel level but your assumption "At this point a new child socket is created and pointed to by the open request" is not quite accurate.

This is all reliant on the application. You have described what typically happen. The server application that has established the listening socket will normally fork a child process. At this point both processes are acting as listening sockets and will accept connections. This is why the first thing that the child process will do is to close the listening socket, and after creating the child the first thing that the listening socket will do is to close the connection. This process is all done by the application and has nothing to do with the kernel.

Sorry, Graemef, but appforce is correct.

There is typically *one* listener socket in *one* server process. It calls "listen()", then it blocks in "accept()". When "accept()" unblocks, a new connection has been established (the 3-way handshake has occurred), a new socket is returned, and the server process will often create a new process or thread to service the new connection (returning back to "accept()" the next connection to arrive on the original listener socket).

The best book on the subject is:

Unix Network Programming, Stevens
http://www.bookpool.com/sm/0131411551

IMHO .. PSM

PS:
Appforce -
In my 2.6 source tree, this is one good kernel module to look at:
/usr/src/linux-2.6.8-24.14/net/socket.c

Sorry,

I guess I misread child socket for child process.

That said I still stand by my description at the application level, if the application forks it will create an exact copy of the parent process and thus there will be two listening sockets at that moment in time.

Thank you for your suggestion! I will read the book and look at that kernel module. And also I am sorry that something in my post may be misleading!