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

david schwartz

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

rick jones

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...

esmond pitt

Why should it? The available() data is still there and can still be
read. It's only when you have to do a network operation that the failure
can be discovered. So if available() returned > 0 probably the next read
would succeed, and the one after that would block forever, or maybe get
a connection reset if you're lucky. The only certain way of discovering
a broken TCP connection is to write to it.