socket stays bound after program terminates

This is a discussion on socket stays bound after program terminates within the Linux Programming forums, part of the Platform Specific Boards category; I'm having a strange issue with sockets in a server program. The server is run from the command line, and ...

  1. #1
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364

    socket stays bound after program terminates

    I'm having a strange issue with sockets in a server program.

    The server is run from the command line, and begins listening on a socket. when connections come in, the process forks and the child handles the connection. the child closes its copy of the listening socket, and the parent closes its copy of the client socket. the problem I am having is that, if a connection comes in, and then I kill the server program and restart it, it cannot bind to the port for about 30 seconds after I kill it. it would seem to me that it would go away immediately, and I could bind to that port again immediately after the process ends.

  2. #2
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364
    never mind... I found the problem. I had to call setsockopt() with option SO_REUSEADDR set.

  3. #3
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by Elkvis View Post
    never mind... I found the problem. I had to call setsockopt() with option SO_REUSEADDR set.
    This gets people all the time. Good on you that you caught it.
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  4. #4
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364
    interesting new problem... even with the SO_REUSEADDR flag set, it won't release the port. I'm really getting confused now.

    Code:
    int on = 1;
    setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
    am I doing something wrong here? I'm calling setsockopt on both the listening and client sockets.

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elkvis View Post
    interesting new problem... even with the SO_REUSEADDR flag set, it won't release the port. I'm really getting confused now.

    Code:
    int on = 1;
    setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));
    am I doing something wrong here? I'm calling setsockopt on both the listening and client sockets.
    What do you mean by "it?" The kernel? True -- it will not release the port. However, SO_REUSEADDR will allow you to re-bind in spite of this.

    This is a fundamental feature of the TCP/IP protocols. You can't change it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364
    Quote Originally Posted by brewbuck View Post
    What do you mean by "it?" The kernel? True -- it will not release the port. However, SO_REUSEADDR will allow you to re-bind in spite of this.
    except that killing the program and then re-starting it still throws the error of not being able to bind to the port, in spite of the SO_REUSEADDR flag being set.

    just out of curiosity, why would the kernel need to keep the port bound for so long after the program exits? it seems to be about 60 seconds after termination.

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elkvis View Post
    except that killing the program and then re-starting it still throws the error of not being able to bind to the port, in spite of the SO_REUSEADDR flag being set.
    That shouldn't be happening. I'd need to see the exact code.

    just out of curiosity, why would the kernel need to keep the port bound for so long after the program exits? it seems to be about 60 seconds after termination.
    To prevent a possible race condition where a packet from an older connection is mistakenly directed to a new one. I do not remember the details, but I'm sure Google can find it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  8. #8
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364
    Quote Originally Posted by brewbuck View Post
    That shouldn't be happening. I'd need to see the exact code.
    I'll post it tomorrow when I get to the office.

  9. #9
    Registered User
    Join Date
    Oct 2006
    Posts
    2,364
    I figured out the problem. I was calling bind before setsockopt. I switched them around and it solved the whole problem.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Storing objects after program terminates
    By ejohns85 in forum C++ Programming
    Replies: 7
    Last Post: 08-25-2009, 06:27 AM
  2. Function call from another .c module
    By Ali.B in forum C Programming
    Replies: 14
    Last Post: 08-03-2009, 11:45 AM
  3. my server program auto shut down
    By hanhao in forum Networking/Device Communication
    Replies: 1
    Last Post: 03-13-2004, 09:49 PM
  4. insufficient memory for tsr
    By manmohan in forum C Programming
    Replies: 8
    Last Post: 01-02-2004, 08:48 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21