Java TCP Socket wait for idle?

Question

I'm not sure if this is more a Java question or TCP question or both:

I have some server code using Apache Mina that runs a server listening for TCP on a given socket. The handler I have extends IoHandlerAdapter. I'm using this to connect a camera to the Java server over HTTP/1.1

The problem is: if I make the connection and then completely disconnect the camera (either pull power or pull network), I have to wait until the sessionIdle method is called to detect that the session is now dead (and then explicitly close the session from the server side).

My question is: Isn't there any way to know that the TCP session was instantly broken by the client? Or is this just the way that TCP sessions / Mina works?

Ideally, sessionIdle would only be for cases where the TCP socket hasn't died but the client (camera) has stopped talking over the socket... and some other mechanism would catch when the socket is actually killed (by the client/network).

NOTE: I am overriding exceptionCaught() but I don't see that being called in the case where I either unplug power or network. It just sits until the idle time then calls sessionIdle().

Thanks!

Answer 1

Unfortunately, the abrupt removal of one end of a connection is not immediately detectable since the end being removed does not have a chance to notify the other end of the connection.

There is no string (so to speak) connecting two ends of a TCP connection, instead there is just an agreement on connection state. The result being that until a timeout is hit, there is no way to know that the other end of the connection has disappeared unless that end of the connection sends a notification of its intent to disconnect.

As an analogy, imagine you are carrying on a conversation with someone in another room, whom you cannot see. When do you consider them to be no longer there? If they tell you they are leaving, and then you hear the door slam shut, it would be reasonable to assume that they have left. However, if they just fail to answer a question you would probably repeat the question, maybe a little louder this time. Then you might wait a little bit, call their name, maybe wait a little bit more for a response, and then perhaps finally walk over to the other room to see if they are still there or not.

This is what TCP basically does (especially if you are sending keep alives), except it has no way to walk over to the other room and can only rely on timeout thresholds being hit to indicate that the other party has left. So when a timeout is hit with no response from the other side, the assumption is made that they have left without telling you.

This is why when the other side of your connection suddenly disappears you have to rely on the timeout to tell you so, since there is simply no other way to know.