Detection other side of socket closed

[Vincent Cantin]

Hi,

Here is my problem :

I am developing a client/server application. I have my server which only
have 1 thread to process the requests of all the clients. I need that none
of the read it makes from the input streams of the socket to be blocking, so
I am reading the bytes available in the input stream before I do my reads so
I am never in a blocking state.

Now, my problem is that I don't know how to detect when a client close his
socket. I saw on the net that usually the programmers are reading the input
stream or writing the output stream in order to receive an IOException, but
when the client close his socket, the available number of byte in the input
stream of the server doesn't change, and I don't know how to make the
detection.

Do you see the paradox ? I need to call a blocking function if I want to to
detect the close of the socket, but in my server I cannot afford to call a
blocking function.

If someone have a magical way to detect in a non-blocking way when a client
close normally his socket, then I will really be happy to heard it.

Thank you,
Vincent

 

[Rune Fauske]

Hi,

Here is my problem :

I am developing a client/server application. I have my server which only
have 1 thread to process the requests of all the clients. I need that none
of the read it makes from the input streams of the socket to be blocking, so
I am reading the bytes available in the input stream before I do my reads so
I am never in a blocking state.

Now, my problem is that I don't know how to detect when a client close his
socket. I saw on the net that usually the programmers are reading the input
stream or writing the output stream in order to receive an IOException, but
when the client close his socket, the available number of byte in the input
stream of the server doesn't change, and I don't know how to make the
detection.

You should probably look into Java NIO
[http://java.sun.com/j2se/1.4.2/docs/guide/nio/]

Do you see the paradox ? I need to call a blocking function if I want to to
detect the close of the socket, but in my server I cannot afford to call a
blocking function.

If someone have a magical way to detect in a non-blocking way when a client
close normally his socket, then I will really be happy to heard it.

Here is an example on how to detect a remote socket close when using
Java NIO [http://javaalmanac.com/egs/java.nio/DetectClosed.html]

 

[Thomas Schodt]

... how to detect when a client close his
socket.

You should probably look into Java NIO
[http://java.sun.com/j2se/1.4.2/docs/guide/nio/]

If someone have a magical way to detect in a non-blocking way when a client
close normally his socket, then I will really be happy to heard it.

Here is an example on how to detect a remote socket close when using
Java NIO [http://javaalmanac.com/egs/java.nio/DetectClosed.html]

It is my understanding that the only guaranteed way of detecting a
broken socket is to use write(); implement a heartbeat/handshake message.

In the case of a (persisting) break on a network cable between two
transit points (routers/switches/hubs) how would the local TCP/IP stack
know that a pending or new read() should throw an exception?

 

[Gordon Beaton]

It is my understanding that the only guaranteed way of detecting a
broken socket is to use write(); implement a heartbeat/handshake
message.

In the case of a (persisting) break on a network cable between two
transit points (routers/switches/hubs) how would the local TCP/IP
stack know that a pending or new read() should throw an exception?

When a socket is closed by the remote (as indicated in the original
post) either read() or write() on the corresponding socket streams can
and should be used to detect EOF. As another poster suggested, the
Java NIO classes can be used instead if non-blocking behaviour is
needed.

A broken physical link is not the same as a closed socket. Since TCP
attempts to handle the situation and recover, communication could
potentially still resume on the same connection. However if you want
to detect that condition before TCP gives up (as it eventually will),
then yes, an application level heartbeat is necessary. It's important
to realize though that you lose some of the resiliency that TCP offers
if you are too quick to close a non-responsive connection.

/gordon

 

[Vincent Cantin]

Hi,

Here is my problem :

I am developing a client/server application. I have my server which only
have 1 thread to process the requests of all the clients. I need that none
of the read it makes from the input streams of the socket to be blocking, so
I am reading the bytes available in the input stream before I do my reads so
I am never in a blocking state.

Now, my problem is that I don't know how to detect when a client close his
socket. I saw on the net that usually the programmers are reading the input
stream or writing the output stream in order to receive an IOException, but
when the client close his socket, the available number of byte in the input
stream of the server doesn't change, and I don't know how to make the
detection.

You should probably look into Java NIO
[http://java.sun.com/j2se/1.4.2/docs/guide/nio/]

Do you see the paradox ? I need to call a blocking function if I want to to
detect the close of the socket, but in my server I cannot afford to call a
blocking function.

If someone have a magical way to detect in a non-blocking way when a client
close normally his socket, then I will really be happy to heard it.

Here is an example on how to detect a remote socket close when using
Java NIO [http://javaalmanac.com/egs/java.nio/DetectClosed.html]

Thank for all of you for the usefull information.
My server will be a success with them.
Java rulez