views:

89

answers:

1

I used to think that using SocketOptionName.ReuseAddress, I can reuse a port that is in TIME_WAIT state. But I tried to experiment with it and it seems it has no effect.

If I check sockets using netstat, and it shows the socket is in TIME_WAIT state and I immediately run the client again, I get the exception:

Only one usage of each socket address (protocol/network address/port) is normally permitted 172.16.16.16:12345

I cannot make anything out of it. Please can you elaborate what SocketOptionName.ReuseAddress is good for?

+1  A: 

Why are you binding your client port in the first place? You probably don't need to and if you don't then it's much better to allow the OS to select an ephemeral port for you and then you wouldn't have this problem in the first place.

Secondly, why do you think it's a good idea to reuse a socket that it's TIME_WAIT; the state exists for a valid reason...

As for why it's not working for you, take a look at the link that I posted in answer to this similar question: http://stackoverflow.com/questions/2605182/when-binding-a-client-tcp-socket-to-a-specific-local-port-with-winsock-so-reusea/2606389#2606389

Len Holgate
Thanks for the answer. In my real application, I am not binding the client to a port. But that application has LOT of incoming connection so it may run out of free ports (not in TIME_WAIT state). To simulate that condition, I explicitly did that.
Hemant
So your actual problem is that you have a server, with inbound connections and they end up in `TIME_WAIT` and you'd rather they didn't. There are, generally, better ways to solve that particular problem: 1) can you move the active close off to the client? 2) if you can't can you do an abortive close and send an `RST` rather than doing a normal close ? etc. Still, at least you tried this route rather than simply deciding to shorten the `TIME_WAIT` period on a machine wide basis... Search on here, there are lots of questions about it.
Len Holgate