tags:

views:

21

answers:

1

As far as my understanding goes, once we complete the 'listen' call with bound socket, all the TCP connections initiated by the client starts succeeding, but, when the accept is called, there is a good amount of possibility that the accept call might fail (due unavailable memory or file descriptors crossing the limit etc).

I ran some simple tests in solaris.

Server: 1. Reduce the max number of file descriptors to 8 using the ulimit command

  1. Set the backlog in listen to 8.

  2. Do a listen.

  3. Call accept in a loop for 8 times and then go to sleep

Client:

  1. Connect around 8 connections.

  2. Go to sleep

Test Result:

On the Client side all connections pass. On the Server Side, accept passes only for 4, and fails for 4. (This is reasonable, considering the fact that 3 file descriptors are for standard, one for listen and then there is space only for 4 more connections). But, the netstat shows all 8 connections as established.

TCP Dump, shows 3-way handshake has succeeded for all 8 connections. When will the server notify the 4 connections on the client that they have failed? (i.e. when will it send a FIN to them?)

I noticed another behaviour also, once the server goes to sleep and then if I kill process by doing a CTRL+C, then I find that the FIN is being sent for those 4 failed connections.

I am a little confused about the behaviour. Any help is very much appreciated.

+2  A: 

From what you describe, my guess is that the OS has indeed established all 8 connections and will buffer any data that the client sends (up to the window size). Once your server frees up some FDs and is able to accept the pending connections, you should be able to read whatever has been sent until then. That would also explain why the connections are terminated when your process is killed.

In short: the connections really are there, but your program can't use them because it has no free FDs.

casablanca