Server-client app: how to check if client hasn't been silently disconnected because of a crash?

Question

In my system clients register through web service on a server and then communicate by peer to peer communication only among clients, without server. When client signs out, he informs server that he's leaving. But if he signs out because of any crash or unexpected situation, server will not be informed. How do you normally handle such situations? I mean, how can I design the process of finding out if user is still connected? The only idea I can think of is that a client application should inform server in intervals that he is connected by, for example, calling some service's method. But this sounds quite lame... How do yo uhandle such situations?

Answer 1

Keep-alive signals are used quite frequently in client-server architectures. I agree, it feels a little... clunky... but it's used commonly enough that you can be forgiven for using it, I think :)

The risk you take is this: if you have a very large number of clients, it might be possible to overwhelm your server with keep-alive signals, if you're not careful.

Also, you would need to consider what a client would do if it cannot access the server, but can access other clients. In this case, the server might think that a client has logged out, even though it's still talking to other clients.

As a result, you might want to consider this: when a client checks in, it reports all the other clients that it has talked to successfully in the past keep-alive period.

If you have control over how the clients behave, you could use a lease method. Each client gets a lease to communicate to other clients. It must continually renew that lease with the server. Once the lease expires, clients must agree not to contact other clients, and request a new lease from the server.

There you go... a bunch of possibilities... maybe you can think of something better.