How to determine reason for socket write failure

Question

Hi,
I'm new to socket programming in general, so please bear with me. I've looked around on the forums quite a bit, and haven't found an answer to this question.
I'm working with server code which creates TCP connections over an air interface with a mobile phone client. Since the air interface is inherently unstable, we rely on the TCP buffering/retry mechanism to store up to its capacity of messages if the client is temporarily non-responsive. Since we are sending small amounts of data, this will actually last for quite a while (several minutes or more depending on how much data we are needing to send). As part of an audit mechanism to detect lost clients, I do a write of a "heartbeat" to the socket and if the write fails, I can assume that either the buffer is full (meaning the mobile "went away" either due to loss of battery power, driving through a very long tunnel, etc.), or the mobile actively disconnected the socket.
However, I'd like to know if there is a way to determine the reason for the write failure? I catch the exception, but as far as I can tell they are all IOExceptions. Is there any way to further delineate the reason for a socket failure?
Any help would be greatly appreciated.
Thanks,
-Lisa

Answer 1

If you're in a hurry, I don't have an answer for you.
That said, it was an intriguing enough question that I did some poking around as well. There is a socket exception class, but generally speaking, the only methods that throw socket exceptions tend to deal with defining, creating and closing the socket.
Communicating through the socket is done through input and output streams, and like any other streams, those throw I/O exceptions. I suspect you're catching IOEs because you're using streams. Unfortunately, even Socket.sendUrgentData( int data ) also returns an IOException rather than an SException.
In the interests of covering all the bases, are the IOE messages unsufficient? That is, try...
   } catch ( IOException ioe ) {
      System.out.println( "IOException: " + ioe.getMessage() );
   }...might give you enough information to make a guess at whether the buffer is full or if the foreign host has closed the connection. I would suspect this feature is architecture dependent - UNIX systems might have more detail than Wintel systems.
As a last resort, you could extend the InputStream class and do the appropriate testing when writing/sending your packet. I would think that the only cases you can test for are whether the buffer is full (by maintaining a copy of the buffer and updating as appropriate), the mobile is currently sending data, or if the mobile is just not available.
Conventional Java isn't really the best for this because I'm not sure the JVM security model really wants to allow you to directly analyze TCP packets (otherwise you could just check for ACK statements). JME might have an easy solution that we didn't know about and you should ask on the appropriate forum. Alternatively, you might want to think about using C to write a library that handles connections this way, and externally call the library from the rest of your Java program.