Question: I have the following problem. My client program monitor for availability of server in the local network (using Bonjour, but it does not rally mater). As soon as a server is "noticed" by the client application, the client tries to create a socket: `Socket(serverIP,serverPort);`.

At some point the client can loose the server (Bonjour says that server is not visible in the network anymore). So, the client decide to `close` the socket, because it is not valid anymore.

At some moment the server appears again. So, the client tries to create a new socket associated with this server. But! The server can refuse to create this socket since it (server) has already a socket associated with the client IP and client port. It happens because the socket was closed by the client, not by the server. Can it happen? And if it is the case, how this problem can be solved?

Well, I understand that it is unlikely that the client will try to connect to the server from the same port (client port), since client selects its ports randomly. But it still can happen (just by chance). Right?

Answer: 
Yes, close the socket, as soon as you detect a failure.

The socket will be "stuck" in "close\_wait" if not closed properly.
Even if the socket is closed, it's state will be in time\_wait for a short period. 

However, if You design the application to use a different local port for each new connection, there is no need to wait for the old socket to be closed. 

(As you are then creating a completly different socket, since a socket is identified by the remote-ip, remote port, local ip and local port.)
Short answer: yes, you should close socket on both ends.

Although the answer is simple, in reality it may be very hard to detect that the peer has stopped responding if you don't build some ACK/NACK scheme into your client-server protocol.

Even with your protocol ACKs your processing thread may be hanging waiting for ACKs that will never come from the client or vice versa.

If you use Blocking I/O, I would start by setting read timeouts on a socket. Unfortunately, if the peer becomes unresponsive, there is no corresponding time-out for the writes.
One blunt instrument that I found has value in our environment is to create blocking Sockets through java.nio methods and then interrupt the processing thread at configurable intervals.

Interrupting processing thread will close socket, but if you pick the timeout large enough you will know that there is a trouble. We chose this approach because application was written initially with blocking I/O and a cost to transition it to non-blocking was very high.

With the non-blocking I/O, though, you may check at a finer-grained interval the status of your connection and react more intelligently to the slow/unresponsive connections.

Though non-blocking I/O requires a higher upfront investment, I think it will pay better dividends in terms of reliability and better throughput later on.