5

I came across the sentence in one java client library:

socket.setReuseAddress(true);

Thought this is used to improve performance, since the SO_REUSEADDR option can indicate that socket can forcibly use the TIME_WAIT port even if it belongs to the other socket.

But Also I found that this option is mostly used in the server-side, to enable the server restarting quickly, not waiting the TIME_WAIT socket to close.

My question is that Is this option useful for the client-side, like this client library? Will this do harmful to the other socket, like some attack?

Thanks a lot!

-Dimi

haonan hu
  • 51
  • 2
  • 1
    It is not *typically* used on the client side, but there is one case where it is - TCP hole punching through a NAT, which requires multiple sockets to be bound to the same local IP/Port at the same time, so they have to use `SO_REUSEADDR`/`SO_REUSEPORT`. – Remy Lebeau Jan 16 '17 at 22:16
  • Thanks very much. I was wondering if there have been any experience that shows it helped a lot on the (client) performance by setting this option ? – haonan hu Jan 17 '17 at 06:42

1 Answers1

4

It depends on what you mean by "client". You also mention "client library", which has nothing to do with it.

This is often misunderstood, SO_REUSEADDR is to be able to reuse a socket in TIME_WAIT, and TIME_WAIT only happens on one side of the TCP connection, the one that initiates the termination sequence i.e. sends the first FIN packet i.e. calls shutdown(SHUT_WR) first or calls close first, although the latter is unclear/may depend on other things such as connection state or platform, reasons why you should not call close before first calling shutdown(SHUT_WR). This article is a very informative as well as the two referenced at the end of the article. It makes clear that TIME_WAIT may occur on the listening (server) side as well as client side, and recommends actually having clients always initiate termination ("active close") so that the server doesn't accumulate sockets in TIME_WAIT, where that would be more of a problem.

haelix
  • 4,245
  • 4
  • 34
  • 56