setting KeepAlive - how can I use it?

  • Thread starter Thread starter liormessinger
  • Start date Start date
L

liormessinger

Hi,

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?

thanks much,
Lior
 
Hi,

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?
Click to expand...

You should be more specific about what exactly you're talking about.

Based on the limited information, I'm going to make the assumption that
you want to set the SO_KEEPALIVE option for a network socket in .NET.
If so, then you should look at the Socket.SetSocketOption() method, and
the SocketOptionName.KeepAlive enumeration value.

Using the KeepAlive option can help you detect a client that's crashed.
However, the default settings will only cause keep-alive packets to be
sent every 2 hours. This may or may not be a frequent-enough interval
for your purposes.

I would generally discourage the use of any sort of "keep-alive" type
functionality. It has its uses, but it is much more common that the
server should not care at all about whether the client is reachable at a
specific point in time, if the server would not otherwise need to
communicate with the client.

If you want a timeout on the protocol, you should simply define that and
implement it. For example, say that if the client has no activity for
more than one hour, the client will simply be dropped and will have to
reconnect if it wants to use the server again.

The big problem with using a "keep-alive" is that it can actually create
connection errors when none would normally have happened. If it's okay
for a client to remain connected for hours or days or whatever without
any actual activity, then just let it be connected for that long.
Otherwise, if you try to communicate with the client, you could find
that you just happen to try to send data to the client during some brief
period of time that the actual communications path was interrupted. In
that case, you wind up detecting a broken connection, creating an error
when in fact if you'd just waited a few moments, the connection might be
okay.

As an example: suppose you've got a client computer that needs to be
moved from one side of the room to the other, requiring the network
cable to be disconnected and reconnected elsewhere. Suppose you happen
to send your "keep alive" at the moment the person was moving it. When
the person plugs the computer in again, all of the sudden they will find
that the server has disconnected them, for no really good reason.

If you are concerned about idle clients using server resources, then
again the right technique is to monitor those resources and define some
policy under which you will disconnect idle clients (on a
least-recently-used basis, for example).

If that's not what you're asking about, you'll need to clarify.

Pete
 
Hi,

You are right - its a about the Sockets framework. I do need to use
the keep alive option.

Now here is the setup: my server listens to a client by calling
Socket.Available (which returns the number of available bytes that
were received on that socket). However, even when the client crashes
this method doesn't throw an exception or anything like that.

How should I use keepalive in c#, with Socket.Available? once I set
keep alive option to true, where can I see a failure should that one
happens?

thanks much


Lior> moved from one side of the room to the other, requiring the
network
 
You are right - its a about the Sockets framework. I do need to use
the keep alive option.
Click to expand...

Why do you need to use KeepAlive?
Now here is the setup: my server listens to a client by calling
Socket.Available (which returns the number of available bytes that
were received on that socket). However, even when the client crashes
this method doesn't throw an exception or anything like that.

How should I use keepalive in c#, with Socket.Available? once I set
keep alive option to true, where can I see a failure should that one
happens?
Click to expand...

I don't really understand your question. KeepAlive is not at all
related to determining the number of bytes you can receive from a Socket.

Also, I'll point out that Socket.Available can at best tell you the
number of bytes that can be retrieved from the Socket at the moment you
get the value of that property. There is no guarantee that a subsequent
call to retrieve the data (e.g. Socket.Receive()) will actually return
that number bytes. There is not even a guarantee that it will return
ANY bytes, never mind that the number of bytes would be at least the
number returned by the property.

More generally, using methods and properties to poll the state of a
Socket is usually not a good idea. The state of the Socket can change
just after you poll the state, and so typically any code that is written
to examine the state is relying on unreliable information.

As far as your client issues go, you will not detect a problem with the
client until some attempt to send data is made. The KeepAlive option
can be used for this purpose, but as I mentioned it isn't by default
going to provide timely information, due to the two-hour delay.

If you really want to detect a client failure in some short period of
time, you should include an explicit keep-alive mechanism in your
application protocol, by requiring the server to poll the client
periodically.

But I reiterate my comment that this is generally not a good design.
You should step back and think about why you believe the server needs to
know about a client failure. Almost all the time, there is a better way
to serve that need than using a keep-alive mechanism to directly detect
the client failure.

You have said you want to detect client failure, but you have not said
_why_ you want to. You have already selected a specific mechanism to
use, without explaining why that mechanism is required and why you think
it's the most appropriate way to address an issue. If you explain _why_
you believe you need to detect the client failure, then more specific
advice can be provided regarding alternate ways to address that need.
For example, having detected a client failure, how does this information
help you? What is your server going to do with that information?

Pete
 
Back
Top