0

After making a tcp connection to a server, I close my linux application and Socket.close() is called.

Checking netstat -pant, I see the connection is in TIME_WAIT status.

This prevents me from making an immediate connection back to the server since I'm using the same port to connect from. Instead, I have to wait for the connection to timeout of the TIME_WAIT status before I can reconnect again.

I've played around -without luck- with the socket methods: set_so_timeout(), set_keepalive(), set_so_linger(), and set_reuseaddr() - exact spelling of the method may not be right in this post.

My question is HOW do I get the connection out of the TIME_WAIT status so I can instantly make a connection again?

Please let me know.

Thanks, jbu

jbu
  • 15,831
  • 29
  • 82
  • 105

1 Answers1

6

The best way to get the connection out of TIME_WAIT is (surprisingly) to wait :-)

That's how TCP/IP works. A session is identified by the tuple (sourceIP, sourcePort, destIP, destPort, protocol) and the reason why you can't re-use it is because there may be packets for it still out in the network somewhere.

TIME_WAIT state is generally twice the maximum packet lifetme and you should not be fiddling with it since that may cause packets to show up from the previous session (which will screw up your current session).

Ideally, you should connect from a different source port, then you will be able to open the session immediately.

Another thing you should watch out for is badly closed sessions. I've always subscribed to the guideline that the client should shut down the session (and shut it down cleanly). This minimizes the possiblity for long-lived half-closed sessions hanging around.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • Yes, the different port solves the problem and I will use that for now. However, the so_linger method description looks like it OUGHT to work if I want to use the same source port. I'm just not sure why it doesn't. – jbu Sep 29 '09 at 02:03
  • 1
    SO_LINGER is definitely not recommended. It's support is, at best, sporadic on non-BSD platforms. – paxdiablo Sep 29 '09 at 02:08
  • I don't think using another connection string is an elegant solution, there should be some way to force the TCP/IP to flush everything in the socket and close the connection. – Monis Iqbal Sep 01 '10 at 09:07
  • 3
    @Monis, the problem isn't something local that you can fix by flushing. There may still be packets floating around on the network. If you reuse the same 5-tuple and one of those old packets shows up, it will get in your way, causing, at best, retries and, at worst, data corruption (in the incredibly unlikely event the packet shows up with the correct sequence numbers). – paxdiablo Sep 01 '10 at 11:12
  • The only solution is to wait but wait how long? Please have a look at my recently posted question which might be related to this issue: http://stackoverflow.com/questions/3616704/jdbc-reconnect-problems-with-teradata-driver-using-spring-and-apache-datasource – Monis Iqbal Sep 01 '10 at 13:39
  • There are rarely any "packets for it still out in the network" after a few hundred milliseconds on the high end and less than tens of milliseconds on the low end. The enormously large timeout is a relic of 100bps networks of yore. Now days a round-trip delay to anywhere in the world connected via fixed line is under 300ms, unless your ISP is horrible. The largest offender of this would be any re-transmission during this timeout. The other end may attempt to resend some data that was not ACKd due to loss. This can take up to 24sec for most TCP stacks before the connection is timed out. – Bengie Oct 20 '17 at 19:06
  • look at this websocket RFC(https://datatracker.ietf.org/doc/html/rfc6455#section-7.1.1) It does recommend that the server terminates the connection because "TIME_WAIT connection is immediately reopened upon a new SYN with a higher seq number" – minex Aug 18 '23 at 22:39