When my client connects to my server application, the client
"registers" by passing a reference to itself to the server. The server
stores these references in an ArrayList so that when it needs to push
information to the client it can.

The problem I'm having is developing an elegant solution to handle
when a client goes away. Right now I catch a SocketException which is
thrown when the server tries to push data to the client. When I catch
this exception I remove the client reference from my ArrayList.

Is there a better way to detect when the client goes away without
having to try and send data to it?

I know I can "deregister" when the client quits, but this doesn't
handle the case when the network connection is lost or the client
crashes.

I'd also like for the client to know when the server has gone away
(crashed or network connection lost).

THANKS!
John

"John" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> When my client connects to my server application, the client
> "registers" by passing a reference to itself to the server. The server
> stores these references in an ArrayList so that when it needs to push
> information to the client it can.
>
> The problem I'm having is developing an elegant solution to handle
> when a client goes away. Right now I catch a SocketException which is
> thrown when the server tries to push data to the client. When I catch
> this exception I remove the client reference from my ArrayList.
>
> Is there a better way to detect when the client goes away without
> having to try and send data to it?

In general, with TCP/IP, the only way to know that the connection is gone is
to send data and get the error.
--
John Saunders
Internet Engineer
(E-Mail Removed)

"John Saunders" <(E-Mail Removed)> wrote in message news:<#(E-Mail Removed)>...
> "John" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > When my client connects to my server application, the client
> > "registers" by passing a reference to itself to the server. The server
> > stores these references in an ArrayList so that when it needs to push
> > information to the client it can.
> >
> > The problem I'm having is developing an elegant solution to handle
> > when a client goes away. Right now I catch a SocketException which is
> > thrown when the server tries to push data to the client. When I catch
> > this exception I remove the client reference from my ArrayList.
> >
> > Is there a better way to detect when the client goes away without
> > having to try and send data to it?
>
> In general, with TCP/IP, the only way to know that the connection is gone is
> to send data and get the error.

I would have thought there was some high-level way to test the
connection. Like an isConnected method or something.

I guess I'll trap the exception and then handle it.

John

"John" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "John Saunders" <(E-Mail Removed)> wrote in message
news:<#(E-Mail Removed)>...
> > "John" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > When my client connects to my server application, the client
> > > "registers" by passing a reference to itself to the server. The server
> > > stores these references in an ArrayList so that when it needs to push
> > > information to the client it can.
> > >
> > > The problem I'm having is developing an elegant solution to handle
> > > when a client goes away. Right now I catch a SocketException which is
> > > thrown when the server tries to push data to the client. When I catch
> > > this exception I remove the client reference from my ArrayList.
> > >
> > > Is there a better way to detect when the client goes away without
> > > having to try and send data to it?
> >
> > In general, with TCP/IP, the only way to know that the connection is
gone is
> > to send data and get the error.
>
> I would have thought there was some high-level way to test the
> connection. Like an isConnected method or something.
>
> I guess I'll trap the exception and then handle it.

As I recall, it's a TCP/IP thing.

Besides, if the other side of the connection just crashed, how would the
network code even know about it? Only by trying to send something to it and
either getting no response or getting an error back.
--
John Saunders
Internet Engineer
(E-Mail Removed)

I use ping in a background thread to monitor this, this sends at the lowest
leve possible and does not need any processing on my application on teh
remote machine.

Joe Robe

"John Saunders" <(E-Mail Removed)> wrote in message
news:eep5r%(E-Mail Removed)...
> "John" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "John Saunders" <(E-Mail Removed)> wrote in message
> news:<#(E-Mail Removed)>...
> > > "John" <(E-Mail Removed)> wrote in message
> > > news:(E-Mail Removed)...
> > > > When my client connects to my server application, the client
> > > > "registers" by passing a reference to itself to the server. The
server
> > > > stores these references in an ArrayList so that when it needs to
push
> > > > information to the client it can.
> > > >
> > > > The problem I'm having is developing an elegant solution to handle
> > > > when a client goes away. Right now I catch a SocketException which
is
> > > > thrown when the server tries to push data to the client. When I
catch
> > > > this exception I remove the client reference from my ArrayList.
> > > >
> > > > Is there a better way to detect when the client goes away without
> > > > having to try and send data to it?
> > >
> > > In general, with TCP/IP, the only way to know that the connection is
> gone is
> > > to send data and get the error.
> >
> > I would have thought there was some high-level way to test the
> > connection. Like an isConnected method or something.
> >
> > I guess I'll trap the exception and then handle it.
>
> As I recall, it's a TCP/IP thing.
>
> Besides, if the other side of the connection just crashed, how would the
> network code even know about it? Only by trying to send something to it
and
> either getting no response or getting an error back.
> --
> John Saunders
> Internet Engineer
> (E-Mail Removed)
>
>