Keepalive - how does it work?

Hi all,

I wondered what are the implications of setting keepalive to true. can
I detect, say, from a server, that a client crashed? and if so, how
can I receive the message (on what callback/function call)?

thanks very much for any idea,
Lior

On Sep 25, 12:27 pm, liormessin...@gmail.com wrote:[color=blue]
> Hi all,
>
> I wondered what are the implications of setting keepalive to true. can
> I detect, say, from a server, that a client crashed? and if so, how
> can I receive the message (on what callback/function call)?[/color]

Keepalives are only to detect if the computer on the other end of an
idle connection (one on which you are not sending data) has become
unreachable. It should only be used in cases where there is no other
way to cleanup connections that would otherwise be "stuck" for days,
weeks, or months. New protocols and programs should use more sensible
application-level methods.

If the connection fails because the other end is unreachable and
cannot respond to a keepalive, that will be considered an error. You
would detect this error the same way you detect other errors (such as
connection reset by peer or send timed out).

For Berkeley sockets API applications, this would mean that the socket
would be considered readable and a 'read' or 'recv' will return a
fatal error indication.

DS

Hi and thanks on the elaborate answer.

I'm actually using c#. My server listens to a client by calling one of
the c# sockets function which is a wrapper around the winsock api (i'm
using Socket.Available which returns the number of available bytes
that were received on that socket). However, even when the client
crashes (or being crashed...) this method doesn't throw an exception
or anything like that.

So maybe I should revise my question on how to use keepalive in c#

but in any case, any ideas?

thanks much
Lior
On Sep 25, 7:17 pm, David Schwartz <dav...@webmaster.com> wrote:[color=blue]
> On Sep 25, 12:27 pm, liormessin...@gmail.com wrote:
>[color=green]
> > Hi all,[/color]
>[color=green]
> > I wondered what are the implications of setting keepalive to true. can
> > I detect, say, from a server, that a client crashed? and if so, how
> > can I receive the message (on what callback/function call)?[/color]
>
> Keepalives are only to detect if the computer on the other end of an
> idle connection (one on which you are not sending data) has become
> unreachable. It should only be used in cases where there is no other
> way to cleanup connections that would otherwise be "stuck" for days,
> weeks, or months. New protocols and programs should use more sensible
> application-level methods.
>
> If the connection fails because the other end is unreachable and
> cannot respond to a keepalive, that will be considered an error. You
> would detect this error the same way you detect other errors (such as
> connection reset by peer or send timed out).
>
> For Berkeley sockets API applications, this would mean that the socket
> would be considered readable and a 'read' or 'recv' will return a
> fatal error indication.
>
> DS[/color]

In comp.protocols.tcp-ip [email]liormessinger@gmail.com[/email] wrote:[color=blue]
> Hi and thanks on the elaborate answer.[/color]
[color=blue]
> I'm actually using c#. My server listens to a client by calling one of
> the c# sockets function which is a wrapper around the winsock api (i'm
> using Socket.Available which returns the number of available bytes
> that were received on that socket). However, even when the client
> crashes (or being crashed...) this method doesn't throw an exception
> or anything like that.[/color]
[color=blue]
> So maybe I should revise my question on how to use keepalive in c#
> but in any case, any ideas?[/color]

The idea is that you design your application-level "protocol" to have
a keepalive mechanism of its own, using its own ideas of how long is
long enough between probes and how long to wait for a response rather
than using setsockopt() to set SO_KEEPALIVE.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...