Question on socket communication....

[subrat chaudhary]

Hi All,

My application does the following:

1. A process does socket, bind and listen. We have set SO_REUSEADDR and SO_REUSEPORT.
2. It then forks a child process.
3. The child process waits on accept on the original socket (that it inherited from the parent).
4. When a client connects to the ip/port, the child handles the communication (accept completes, then does send/recv).
5. Now I kill the parent (kill -9 )
6. I start the parent process again. It does the same socket, bind and listen with the same options as mentioned above.
7. Parent again forks a child process.
8. Child process waits on accept on the original socket (that is inherited from parent).
9. When a client connects to the ip/port, the second child does not get any connection, it is always the first child which is getting the connections.

Why is this so that the second child does not get any connection ? Is this normal behaviour ? Are there any options that we are missing to set ?

Thanks,
Subrat

[Sandman!]

You are forking server processes listening for connections on a specified port. This won't work as the second child process will try to bind to the same port that is already in use by the first child process; owing to an established socket connection. This causes contention for the same port between the two child processes. I don't know your code but it might help if you included error checking into it to decipher the return codes from the bind, listen, and accept.

~hope it helps

[A. Clay Stephenson]

You are doing this all wrong. You should be listening for connections on your dedicated port. You then fork() and the child establishes a connection using a port in the anonymous range and the parent goes back to listening for request on the dedicated port.

[James R. Ferguson]

Hi:

...and get out of the 'kill -9' habit. Killing processes this way doesn't allow them to trap the signal and cleanup temporary files or shared memory segments. (The failure to cleanup shared memory can be particularly harmful. Try a 'kill -9' on your 'fbackup' sessions and watch your memory utilization climb!). A 'kill -9' should be the 'kill' of last resort. Start with a 'kill -hup' and then 'kill -term' and then lastly 'kill -9'.

Regards!

...JRF...

[sjoshi]

Replying on behalf of Subrat. Thanks a lot for your replies. Here are my comments:

Sandman,

Since there is usage of SO_REUSEPORT, we dont get error in bind and listen.
As soon as the first child (child of the first parent) is killed, the second child is able to receive requests.


A Clay Stephenson,

I didnt quite understand your explaination.

Here is what we do:

The child does the accept. The original socket (inherited from parent) is used in the accept call. Since we have set it as non-blocking, accept gives EAGAIN. We use select to get to know when the socket is ready for accept. When a client connects, the select completes telling that the socket is ready. The accept returns a new file descriptor. We use the new file descriptor for future communication (send/recv) and the original socket is again used to do the accept.

So when the same logic is done in the second child (child of the second parent), we get EAGAIN in accept. We call select. When a client connects, the second child's select does not complete. We are interested in knowing the reason for this.

Thanks,

Shantanu...