How to fast close socket? - Unix

This is a discussion on How to fast close socket? - Unix ; Hi, I noticed that after my program exits, there still an entry when I run 'netstat -np', the socket is a TCP socket bind() into a given port, after the exit, seems the state of the connection show TERM-WAIT(or something ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: How to fast close socket?

  1. How to fast close socket?

    Hi,

    I noticed that after my program exits, there still an entry when I run
    'netstat -np', the socket is a TCP socket bind() into a given port,
    after the exit, seems the state of the connection show TERM-WAIT(or
    something else) for a few seconds.

    This bothers me because I want to restart the program very quickly,
    which will encounter the bind() errror coz the previous bind still
    running in kernel side(I guess).

    Is there a method to immediately shut down the socket completely
    before I exit() the program?

    Thanks.
    Bin

  2. Re: How to fast close socket?

    On Aug 26, 2:09 pm, Bin Chen wrote:
    > Hi,
    >
    > I noticed that after my program exits, there still an entry when I run
    > 'netstat -np', the socket is a TCP socket bind() into a given port,
    > after the exit, seems the state of the connection show TERM-WAIT(or
    > something else) for a few seconds.
    >
    > This bothers me because I want to restart the program very quickly,
    > which will encounter the bind() errror coz the previous bind still
    > running in kernel side(I guess).
    >
    > Is there a method to immediately shut down the socket completely
    > before I exit() the program?


    Isn't setsockopt SO_REUSEADDR what you want?


  3. Re: How to fast close socket?

    On Aug 26, 9:09 am, Bin Chen wrote:
    > Hi,
    >
    > I noticed that after my program exits, there still an entry when I run
    > 'netstat -np', the socket is a TCP socket bind() into a given port,
    > after the exit, seems the state of the connection show TERM-WAIT(or
    > something else) for a few seconds.
    >
    > This bothers me because I want to restart the program very quickly,
    > which will encounter the bind() errror coz the previous bind still
    > running in kernel side(I guess).
    >
    > Is there a method to immediately shut down the socket completely
    > before I exit() the program?
    >
    > Thanks.
    > Bin


    You need to call 'shutdown' on the socket before exit (even a signal-
    caused exit,) otherwise it will stay open until the kernel gets around
    to realizing that it's of no more use.
    Kevin P. Barry

  4. Re: How to fast close socket?

    On Aug 26, 7:09 am, Bin Chen wrote:
    > I noticed that after my program exits, there still an entry when I run
    > 'netstat -np', the socket is a TCP socket bind() into a given port,
    > after the exit, seems the state of the connection show TERM-WAIT(or
    > something else) for a few seconds.


    Yes, that's there fore a reason. Please go read "UNIX Network
    Programming, volume 1" by W. Richard Stevens. There's an explanation
    of the TIME-WAIT state there, plus lots of other information that I
    believe you would find useful.


    > This bothers me because I want to restart the program very quickly,
    > which will encounter the bind() errror coz the previous bind still
    > running in kernel side(I guess).


    As mentioned by others, you need the SO_REUSEADDR option.


    > Is there a method to immediately shut down the socket completely
    > before I exit() the program?


    Without possibly losing data? No. But because of SO_REUSEADDR you
    don't need to do that anyway.


    Philip Guenther

  5. Re: How to fast close socket?

    On Aug 26, 6:09*am, Bin Chen wrote:

    > Is there a method to immediately shut down the socket completely
    > before I exit() the program?


    No. Consider that when your program is shutting down, there might
    still be a few stale packets live on the network that the kernel might
    receive after your program terminates. If you could shut down the
    socket completely, and one of those packets were received, how would
    the kernel know not to reply to them?

    The correct solution is to allow the new bind to replace the old bind,
    not to end the old bind too early.

    DS

  6. Re: How to fast close socket?

    On Aug 26, 10:12 pm, David Schwartz wrote:
    > On Aug 26, 6:09 am, Bin Chen wrote:
    >
    > > Is there a method to immediately shut down the socket completely
    > > before I exit() the program?

    >
    > No. Consider that when your program is shutting down, there might
    > still be a few stale packets live on the network that the kernel might
    > receive after your program terminates. If you could shut down the
    > socket completely, and one of those packets were received, how would
    > the kernel know not to reply to them?


    I have never fully understood this issue. If such packets did arrive,
    I would expect the kernel to reply with a RST. What is wrong with
    that?



  7. Re: How to fast close socket?

    On Aug 27, 12:52 am, fjbl...@yahoo.com wrote:
    > On Aug 26, 10:12 pm, David Schwartz wrote:

    ....
    > > Consider that when your program is shutting down, there
    > > might still be a few stale packets live on the network that the
    > > kernel might receive after your program terminates. If you
    > > could shut down the socket completely, and one of those
    > > packets were received, how would the kernel know not to
    > > reply to them?

    >
    > I have never fully understood this issue. If such packets did arrive,
    > I would expect the kernel to reply with a RST. What is wrong with
    > that?


    Indeed, that's what happens, in my experience. If there is data that
    was written to the socket but that has not actually been fully sent
    (e.g., acked by the other end for TCP) then the close() may block, as
    controlled by the SO_LINGER socket option. But for data going the
    other direction, if you just close() the socket then any further data
    packets received will prompt RSTs from the kernel. It's kinda like
    the TCP version of a SIGPIPE.

    (This behavior is quite common with protocols using TLS. For example,
    an LDAP client that negotiated TLS will normally shutdown a connection
    by sending an LDAP 'unbind' request, then send the TLS close_notify
    alert, and then close the socket, sending a FIN. The server will
    respond to the close_notify alert with its own close_notify alert, but
    because the client has already called close() it'll generate a RST
    back from the client to the server. If the client had waited for the
    server's close_notify before calling close() then there would be no
    RSTs, just FINs.)


    Philip Guenther

  8. Re: How to fast close socket?

    On Aug 26, 11:52*pm, fjbl...@yahoo.com wrote:

    > > No. Consider that when your program is shutting down, there might
    > > still be a few stale packets live on the network that the kernel might
    > > receive after your program terminates. If you could shut down the
    > > socket completely, and one of those packets were received, how would
    > > the kernel know not to reply to them?


    > I have never fully understood this issue. *If such packets did arrive,
    > I would expect the kernel to reply with a RST. *What is wrong with
    > that?


    They serve no purpose and are prohibited by the standard.

    DS

  9. Re: How to fast close socket?

    On Aug 27, 6:56 am, David Schwartz wrote:
    > On Aug 26, 11:52 pm, fjbl...@yahoo.com wrote:
    >
    > > > No. Consider that when your program is shutting down, there might
    > > > still be a few stale packets live on the network that the kernel might
    > > > receive after your program terminates. If you could shut down the
    > > > socket completely, and one of those packets were received, how would
    > > > the kernel know not to reply to them?

    > > I have never fully understood this issue. If such packets did arrive,
    > > I would expect the kernel to reply with a RST. What is wrong with
    > > that?

    >
    > They serve no purpose and are prohibited by the standard.


    Well, that sort of begs the question, so let me rephrase. Imagine a
    second standard that does not have a TIME_WAIT state; where a host may
    tear down the connection completely and forget all about it. This
    standard has the advantage over the real one that the host need not
    spend resources remembering a connection that it no longer cares
    about, and that SO_REUSEADDR is not needed. It would have the
    disadvantage that a few "unnecessary" RST packets might be sent, which
    would not be sent under the real standard, and would use a little bit
    of extra bandwidth and processing time by the remote host. So there
    is one tradeoff.

    Are you saying, then, that the reason the standard specifies TIME_WAIT
    is to save bandwidth by avoiding the transmission of the unnecessary
    RSTs? Or does sending these packets have some other undesired
    effect? In other words, are there other problems I would encounter in
    designing my hypothetical second standard?

  10. Re: How to fast close socket?

    On Aug 27, 8:37*am, fjbl...@yahoo.com wrote:

    > Well, that sort of begs the question, so let me rephrase. *Imagine a
    > second standard that does not have a TIME_WAIT state; where a host may
    > tear down the connection completely and forget all about it. *This
    > standard has the advantage over the real one that the host need not
    > spend resources remembering a connection that it no longer cares
    > about, and that SO_REUSEADDR is not needed.


    SO_REUSEADDR is not needed anyway, as a host could simply implement it
    by default or automatically for all sockets. SO_REUSEADDR is a
    separate decision to prevent one program from taking a port that was
    too recently used by another.

    >*It would have the
    > disadvantage that a few "unnecessary" RST packets might be sent, which
    > would not be sent under the real standard, and would use a little bit
    > of extra bandwidth and processing time by the remote host. *So there
    > is one tradeoff.


    Right, and those RST packets could cause the connection to terminate
    abnormally on the other end.

    > Are you saying, then, that the reason the standard specifies TIME_WAIT
    > is to save bandwidth by avoiding the transmission of the unnecessary
    > RSTs?


    No, it's to prevent those RSTs from resetting the connection on the
    other end. This is part of the last ACK problem. There is no way to
    simultaneously close the connection on both ends, so you cannot assume
    the connection is closed on the other end just because it's closed on
    your end.

    >*Or does sending these packets have some other undesired
    > effect?*In other words, are there other problems I would encounter in
    > designing my hypothetical second standard?


    What would stop those RSTs from resetting the connection if it was
    "almost closed" on the other end, as opposed to completely closed?

    DS

  11. Re: How to fast close socket?

    fjblurt@yahoo.com writes:
    > On Aug 27, 6:56 am, David Schwartz wrote:
    >> On Aug 26, 11:52 pm, fjbl...@yahoo.com wrote:
    >> > > No. Consider that when your program is shutting down, there might
    >> > > still be a few stale packets live on the network that the kernel might
    >> > > receive after your program terminates. If you could shut down the
    >> > > socket completely, and one of those packets were received, how would
    >> > > the kernel know not to reply to them?
    >> > I have never fully understood this issue. If such packets did arrive,
    >> > I would expect the kernel to reply with a RST. What is wrong with
    >> > that?

    >>
    >> They serve no purpose and are prohibited by the standard.

    >
    > Well, that sort of begs the question, so let me rephrase. Imagine a
    > second standard that does not have a TIME_WAIT state; where a host may
    > tear down the connection completely and forget all about it.


    [...]

    > It would have the
    > disadvantage that a few "unnecessary" RST packets might be sent, which
    > would not be sent under the real standard, and would use a little bit
    > of extra bandwidth and processing time by the remote host. So there
    > is one tradeoff.
    >
    > Are you saying, then, that the reason the standard specifies TIME_WAIT
    > is to save bandwidth by avoiding the transmission of the unnecessary
    > RSTs?


    That's not the purpose of TIME-WAIT (there is an explanation of this
    in UNP1 which is probably better than any I can give). After a
    connection has been closed, it enters the TIME-WAIT state and stays
    there for two times the maximum segment lifetime (MSL). This is done
    in order to prevent old, duplicate segments which may still be buffered
    somewhere from mistakenly being accepted for a new connection in case
    the sequence number spaces of both connections happen to overlap
    suitably.


  12. Re: How to fast close socket?

    On Aug 27, 7:56 am, David Schwartz wrote:
    > On Aug 26, 11:52 pm, fjbl...@yahoo.com wrote:

    ....
    > > I have never fully understood this issue. If such packets did
    > > arrive, I would expect the kernel to reply with a RST. What is
    > > wrong with that?

    >
    > They serve no purpose and are prohibited by the standard.


    Really? I think you're saying that a system that sends RST packets in
    response to data packets after the local end has decided to stop
    accepting data on that connection ever again is violating some
    standard. Or am I misinterpreting what you said?

    If my understanding is correct: do you have a reference for the
    standard and where in it that prohibition could be found? All the
    UNIX systems I've encountered would appear to violate it.


    Philip Guenther

  13. Re: How to fast close socket?

    On Aug 27, 2:00*pm, "guent...@gmail.com" wrote:

    > Really? *I think you're saying that a system that sends RST packets in
    > response to data packets after the local end has decided to stop
    > accepting data on that connection ever again is violating some
    > standard. *Or am I misinterpreting what you said?


    No, I didn't say that.

    > If my understanding is correct: do you have a reference for the
    > standard and where in it that prohibition could be found? *All the
    > UNIX systems I've encountered would appear to violate it.


    Huh? We were talking about a how you shut down a connection, not what
    you do after you've shut it down.

    DS

  14. Re: How to fast close socket?

    Rainer Weikusat wrote:
    > That's not the purpose of TIME-WAIT (there is an explanation of this
    > in UNP1 which is probably better than any I can give). After a
    > connection has been closed, it enters the TIME-WAIT state and stays
    > there for two times the maximum segment lifetime (MSL). This is done
    > in order to prevent old, duplicate segments which may still be
    > buffered somewhere from mistakenly being accepted for a new
    > connection in case the sequence number spaces of both connections
    > happen to overlap suitably.


    I'd say you cover it pretty well.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  15. Re: How to fast close socket?

    On Aug 27, 5:57 pm, David Schwartz wrote:
    > On Aug 27, 2:00 pm, "guent...@gmail.com" wrote:
    >
    > > Really? I think you're saying that a system that sends RST
    > > packets in response to data packets after the local end has
    > > decided to stop accepting data on that connection ever again
    > > is violating some standard. Or am I misinterpreting what you
    > > said?

    >
    > No, I didn't say that.


    Okay, I must have misunderstood you when you wrote, two messages back
    in this thread:


    > On Aug 26, 11:52 pm, fjbl...@yahoo.com wrote:
    >
    > > > No. Consider that when your program is shutting down,
    > > > there might still be a few stale packets live on the network
    > > > that the kernel might receive after your program terminates.
    > > > If you could shut down the socket completely, and one of
    > > > those packets were received, how would the kernel know not
    > > > to reply to them?

    > >
    > > I have never fully understood this issue. If such packets did
    > > arrive, I would expect the kernel to reply with a RST. What is
    > > wrong with that?

    >
    > They serve no purpose and are prohibited by the standard.


    What is it that serves no purpose and is prohibited by the standard?
    (And which standard?)


    Philip Guenther

  16. Re: How to fast close socket?

    In article
    <03d1179a-819a-4b96-9a12-dbc1711cf57a@x35g2000hsb.googlegroups.com>,
    "guenther@gmail.com" wrote:

    > On Aug 27, 7:56 am, David Schwartz wrote:
    > > On Aug 26, 11:52 pm, fjbl...@yahoo.com wrote:

    > ...
    > > > I have never fully understood this issue. If such packets did
    > > > arrive, I would expect the kernel to reply with a RST. What is
    > > > wrong with that?

    > >
    > > They serve no purpose and are prohibited by the standard.

    >
    > Really? I think you're saying that a system that sends RST packets in
    > response to data packets after the local end has decided to stop
    > accepting data on that connection ever again is violating some
    > standard. Or am I misinterpreting what you said?


    Read the rest of the thread. The problem isn't with sending RST packets
    in response to delayed packets.

    The problem is that if you don't reserve the port number, a new
    connection could reuse it. And then you WON'T send RST packets when you
    should have, because those packets might be viewed as valid packets for
    the new connection, rather than as delayed packets from the old one.

    As an analogy, if you cancel your ISP account, the ISP often reserves
    your email address for a few months. This way, if you don't send out
    address change notices to everyone, they'll start getting bounces,
    rather than unknowingly send to the new customer who got your account
    name.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  17. Re: How to fast close socket?

    Rick Jones writes:
    > Rainer Weikusat wrote:
    >> That's not the purpose of TIME-WAIT (there is an explanation of this
    >> in UNP1 which is probably better than any I can give). After a
    >> connection has been closed, it enters the TIME-WAIT state and stays
    >> there for two times the maximum segment lifetime (MSL). This is done
    >> in order to prevent old, duplicate segments which may still be
    >> buffered somewhere from mistakenly being accepted for a new
    >> connection in case the sequence number spaces of both connections
    >> happen to overlap suitably.

    >
    > I'd say you cover it pretty well.


    Not really. It's actually both. One reason for TIME-WAIT is so that a
    retransmitted FIN from the other end is properly acknowledged instead
    of triggering a RST, which would be interpreted as error, and the other
    is dealing with left-over duplicates. RFC793 mentions only the first.

  18. Re: How to fast close socket?

    On Aug 27, 7:37*pm, "guent...@gmail.com" wrote:

    > > > I have never fully understood this issue. *If such packets did
    > > > arrive, I would expect the kernel to reply with a RST. *What is
    > > > wrong with that?

    >
    > > They serve no purpose and are prohibited by the standard.

    >
    > What is it that serves no purpose and is prohibited by the standard?
    > (And which standard?)


    Sending a RST in response to a valid packet on a connection that has
    not completely closed yet. The kernel must remember recently-closed
    connections for a certain period of time in order to not abort the
    possibly-still-closing connection on the other side. This is required
    by the TCP specification, and is required by logic due to the
    inability to do anything simultaneously on both ends.

    See this FAQ entry:
    http://www.developerweb.net/forum/showthread.php?t=2941

    (Note that this is not as directly related to the main issue in this
    thread as I may have stated or implied. There is no reason to keep the
    information associated with the listening port around just because it
    still has connections that must be kept around.)

    DS

  19. Re: How to fast close socket?

    On Aug 28, 11:48 am, David Schwartz wrote:
    > On Aug 27, 7:37 pm, "guent...@gmail.com" wrote:

    ....
    > > What is it that serves no purpose and is prohibited by the
    > > standard? (And which standard?)

    >
    > Sending a RST in response to a valid packet on a connection
    > that has not completely closed yet.


    ....but you don't define "completely closed".

    Would you agree that a connection for which one end is in FIN_WAIT_1
    or FIN_WAIT_2 is certainly "not completely closed"? After all, data
    may still flow in one direction on the connection, with ACKs flowing
    the other way, and such a connection is often called "half closed".
    Or is it possible for a "half closed" connection like that to meet
    your criteria for "completely closed"?

    Would you agree that an in-window data packet for such a half-closed
    TCP connection would be "a valid packet"?

    (I'm trying to understand what circumstances your "is prohibited"
    claim applies to.)


    > See this FAQ entry:
    > http://www.developerweb.net/forum/showthread.php?t=2941


    Yes, I understand the purpose of TIME_WAIT. My concern in here
    is with the states before that, FIN_WAIT_* in particular, and RSTs
    sent from those states.


    > (Note that this is not as directly related to the main issue in
    > this thread as I may have stated or implied. There is no reason
    > to keep the information associated with the listening port
    > around just because it still has connections that must be kept
    > around.)


    Agreed.


    Philip Guenther

  20. Re: How to fast close socket?

    On Aug 28, 2:25*pm, "guent...@gmail.com" wrote:

    > On Aug 28, 11:48 am, David Schwartz wrote:


    > > Sending a RST in response to a valid packet on a connection
    > > that has not completely closed yet.


    > ...but you don't define "completely closed".


    Sorry. A connection is completely closed on one end if it has no
    intention of sending any further packets associated with that
    connection. A connection is completely closed as soon as you report a
    successful close to the application. A connection is completely closed
    as soon as it can no longer succeed or fail since it already has.

    > Would you agree that a connection for which one end is in FIN_WAIT_1
    > or FIN_WAIT_2 is certainly "not completely closed"? *After all, data
    > may still flow in one direction on the connection, with ACKs flowing
    > the other way, and such a connection is often called "half closed".
    > Or is it possible for a "half closed" connection like that to meet
    > your criteria for "completely closed"?
    >
    > Would you agree that an in-window data packet for such a half-closed
    > TCP connection would be "a valid packet"?
    >
    > (I'm trying to understand what circumstances your "is prohibited"
    > claim applies to.)


    Sorry for not being more precise, but I thought it was clear from
    context. I'm talking about the time period in which you must remember
    the connection only to respond to any packets that might arrive even
    though the connection is closed on your end. (You've already reported
    a close to user space, you know that there have been no errors on the
    connection. All your decisions are already irrevocably made.)

    DS

+ Reply to Thread
Page 1 of 2 1 2 LastLast