java socket 断开连接,检查ClientSocket是否在java中断开连接

This is a follow up to:

Basically, I have a server loop that manages a connection to one solitary client. At one point in the loop, if a ClientSocket exists it attempts a read to check if the client is still connected:

if (bufferedReader.read()==-1 ) {

logger.info("CONNECTION TERMINATED!");

clientSocket.close();

setUpSocket(); //sets up the server to reconnect to the client

}else{

sendHeartBeat(); //Send a heartbeat to the client

}

The problem is, that once a socket has been created the application will hang on the read, I assume waiting for data that will never come, since the client never sends to the server. Before this was OK, because this correctly handled disconnects (the read would eventually fail when the client disconnected) and the loop would attempt reestablish the connection. However, I now have added the above sendHeartBeat() method, which periodically lets the client know the server is still up. If the read is holding the thread then the heartbeats never happen!

So, I assume I am testing if the connection is still up incorrectly. I could, as a quick hack, run the bufferedReader.read() in a seperate thread, but then I'll have all sorts of concurrency issues that I really don't want to deal with.

So the question is a few fold:

1) Am I checking for a client disconnect correctly?

2) If not, how should I do it?

3) If I am doing it correctly how I do I get the read to not hold the process hostage? Or is threading the only way?

解决方案

When you create your socket, first set a timeout:

private int timeout = 10000;

private int maxTimeout = 25000;

clientSocket.setSoTimeout(timeout);

With this, if a read times out you'll get java.net.SocketTimeoutException (which you have to catch). Thus, you could do something like this, assuming you've previously set the SO_TIMEOUT as shown above, and assuming that the heartbeat will always get a response from the remote system:

volatile long lastReadTime;

try {

bufferedReader.read();

lastReadTime = System.currentTimeMillis();

} catch (SocketTimeoutException e) {

if (!isConnectionAlive()) {

logger.info("CONNECTION TERMINATED!");

clientSocket.close();

setUpSocket(); //sets up the server to reconnect to the client

} else {

sendHeartBeat(); //Send a heartbeat to the client

}

}

public boolean isConnectionAlive() {

return System.currentTimeMillis() - lastReadTime < maxTimeout;

}

A common way of handling this is setting the timeout to some number (say 10 seconds) and then keeping track of the last time you successfully read from the socket. If 2.5 times your timeout have elapsed, then give up on the client and close the socket (thus sending a FIN packet to the other side, just in case).

If the heartbeat will not get any response from the remote system, but is just a way of ultimately generating an IOException earlier when the connection has fallen down, then you could do this (assuming that the sendHeartBeat itself will not throw an IOException):

try {

if (bufferedReader.read() == -1) {

logger.info("CONNECTION TERMINATED with EOF!");

resetConnection();

}

} catch (SocketTimeoutException e) {

// This just means our read timed out ... the socket is still good

sendHeartBeat(); //Send a heartbeat to the client

} catch (IOException e) {

logger.info("CONNECTION TERMINATED with Exception " + e.getMessage());

resetConnection();

}

....

private void resetConnection() {

clientSocket.close();

setUpSocket(); //sets up the server to reconnect to the client

}