Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Detection other side of socket closed

Reply
Thread Tools

Detection other side of socket closed

 
 
Vincent Cantin
Guest
Posts: n/a
 
      09-09-2004
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


 
Reply With Quote
 
 
 
 
Rune Fauske
Guest
Posts: n/a
 
      09-09-2004
In article <(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> 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]

--
Rune Fauske
 
Reply With Quote
 
 
 
 
Thomas Schodt
Guest
Posts: n/a
 
      09-09-2004
Rune Fauske wrote:

> In article <(E-Mail Removed)>,
> (E-Mail Removed) says...
>
>> ... 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?
 
Reply With Quote
 
Gordon Beaton
Guest
Posts: n/a
 
      09-09-2004
On Thu, 09 Sep 2004 10:44:13 +0100, Thomas Schodt wrote:
> 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

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
 
Reply With Quote
 
Vincent Cantin
Guest
Posts: n/a
 
      09-10-2004
> > 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]
>
> --
> Rune Fauske


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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 1 01-27-2009 05:05 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48,'Address already in use') Jean-Paul Calderone Python 0 01-27-2009 01:41 PM
How to tell when a socket is closed on the other end? billiejoex Python 6 07-27-2007 04:40 AM
Determining of a Socket has been closed by the other side. Dave Rudolf Java 3 12-31-2003 05:27 AM
Opera - .closed not accessible if window is closed? Matt Kruse Javascript 5 09-09-2003 01:27 AM



Advertisments