Socket programming

[Srinivasan Rajagopal]

Hi all,
In my socket program, how do i check whether the socket is alive or not at present(for already connected socket). This information is useful for me to close the socket and its thread in my server program.

[Jon Dornback]

there is probably a much more efficient/elegant solution, but a quick test is to try to open an input or output stream, or read/write to the socket stream. if an IOExecption is thrown, most likely the socket is not alive.

[Srinivasan Rajagopal]

Thanks for your suggestion. I tried to write data in outputstream. Sometimes, it does not throw the exception. I am running my program in Sun Solaris. Thus, i felt it may not be the reliable way for checking the socket. Other suggested options i have yet to check.

[Lasse Koskela]

SDK 1.4 includes methods isClosed(), isConnected() for checking the status of a Socket.

[Peter den Haan]

Make sure to implement some form of application-level pinging or at the very least enable TCP/IP keepalive if you want a somewhat accurate indication of whether you are, indeed, still connected or not. Quoth the TCP/IP FAQ:

Detecting crashed systems over TCP/IP is difficult. TCP doesn't require any transmission over a connection if the application isn't sending anything, and many of the media over which TCP/IP is used (e.g. Ethernet) don't provide a reliable way to determine whether a particular host is up. If a server doesn't hear from a client, it could be because it has nothing to say, some network between the server and client may be down, the server or client's network interface may be disconnected, or the client may have crashed. Network failures are often temporary (a thin Ethernet will appear down while someone is adding a link to the daisy chain, and it often takes a few minutes for new routes to
stabilize when a router goes down) and TCP connections shouldn't be dropped as a result.
Keepalives are a feature of the sockets API that requests that an empty packet be sent periodically over an idle connection; this should evoke an acknowledgement from the remote system if it is still up, a reset if it has rebooted, and a timeout if it is down. These are not normally sent until the connection has been idle for a few hours. The purpose isn't to detect a crash immediately, but to keep unnecessary resources from being allocated forever.

- Peter
[ February 24, 2003: Message edited by: Peter den Haan ]