Identifying server timeout on a Socket
I am using a Socket to connect to an ftp server that automatically times out the connection after 3 minutes of inactivity. I have tried to set up conditionals to determine if the server has timed out the connection before I send a ftp command but none of them work. After the server has timed me out, these functions still return as follows:
1.) isConnected() returns true
2.) isBound() returns true
3.) inputShutdown() returns false
4.) outputShutdown() returns false
5.) isClosed() returns false
How can I determine if the server timed me out if all these "test" methods return results that are the same as a "non-timed out" socket returns?
Thank you.
# 2
All those methods do is tell you whether you've done the corresponding operationat your end. Not the other end. So:
1.) isConnected() returns true
always after you have called called Socket.connect() successfully or constructed the Socket with a host:port. If you want to know whether the other end is still connected the only reliable technique in TCP is to write to it. If a read returns -1 or null or EOFException (depending on the method) the other end has either closed its socket or shutdown its output (see below).
2.) isBound() returns true
always after you have called Socket.bind() or Socket.connect() or constructed one with a host:port. If the other end wasn't bound you wouldn't even have a connection.
3.) inputShutdown() returns false
Always until you have called Socket.shutdownInput(). There is no reliable platform-independent way of discovering whether the other end has done this.
4.) outputShutdown() returns false
Always until you have called Socket.shutdownOutput(). The only way to discover whether the other end has done is is to read: if you get -1/null/EOFException the other end has either closed the socket or shutdown its output.
5.) isClosed() returns false
Always until you have closed the Socket or its input or output stream. The only way to discover whether the other end has closed is to read, but even then you can't be sure: see above. Or you could write and trap the IOException that eventually results.
TCP/IP has no 'dial tone', unlike earlier protocols such as SNA, so no state information about the other end is available to an application.
ejpa at 2007-7-12 19:56:16 >
