Pattern to implement heartbeat between server and the client

Question

I would like to implement a heartbeat functionality in the server that would periodically alert window clients of its liveness. There are few ideas I am considering but would appreciate suggestions and examples/references

• have a separate thread that would send a heartbeat to connected clients

• have different types of heartbeat to indicating different states of the server (slow, fast, overwhelmed with clients, up and ready)

• perhaps let clients subscribe to different levels, have up heartbeat sent by default

I would really like to see how it is done in practice, examples are best.

EDIT 1 clients and server are not web-based! (server might migrate to the web, but I dont think it should change the protocol much)

Answer 1

Using the pull model mentioned by Josh is the simplest approach. First of all, you'll get past a lot of security issues with that. No need to worry about client-side firewalls. Plus, you don't need to worry about having to open the same port on each client, or opening dynamic ports and notifying the server about what port on what client is being used.

In addition, you won't have to maintain a subscriber list on the server. Plus, you will not need to worry about cleaning up the subscriber list if a client disconnects in a not so clean manner (application crash, power failure, etc).

Basically, a simple polling from the client to a service on the server is the simplest and cleanest approach, IMHO. I've used it several times. You can even have the polling interval be user-configurable if you choose.

Edit:

While I cannot provide a reference or example code, I'll describe what I've done in the past.

Basically, I had a web service that, when queried, would return the state of the system. This web service obviously ran on the server. The clients, when started, would launch a separate thread that would query the web service every 30 seconds to get the state of the server system. Then, the UI would be updated to indicate that state. Once that task was complete the thread would go back to sleep for 30 seconds. The update time was configurable through a configuration file. Just make sure to trap errors so that if the request to the service fails for a reason other than the server being down, the entire application doesn't crash.

Answer 2

This is almost surely overkill, but there is an entire (and very lively) discipline looking at classes of failure detectors, what kinds of assurances they can provide, and how they can practically be implemented. For those wanting to go a bit further than this questioner implies, have a look at:

Book Series - 
Book Title  - Distributed Computing
Chapter Title  - On the Impact of Fast Failure Detectors on Real-Time Fault-Tolerant Systems
First Page  - 354
Last Page  - 369
Copyright  - 2002
Author  - Marcos K. Aguilera
Author  - Gérard Le Lann
Author  - Sam Toueg
DOI  - 10.1007/3-540-36108-1_24
Link  - http://www.springerlink.com/content/e03yf4etbnle9728

Book Title  - Distributed Algorithms
Chapter Title  - Heartbeat: A timeout-free failure detector for quiescent reliable communication
First Page  - 126
Last Page  - 140
Copyright  - 1997
Author  - Marcos Kawazoe Aguilera
Author  - Wei Chen
Author  - Sam Toueg
DOI  - 10.1007/BFb0030680
Link  - http://www.springerlink.com/content/dj5n71hl17841416

Also, it's not clear from the question, but if the language in question is Java, an excellent resource on this topic is: Introduction to Reliable Distributed Programming , with lots of excellent sample code.

Answer 3

What kind of client are we talking about? Windows client or asp.net? There are two very general patterns for this. You can either push or pull the data. Pushing doesn't work if your on the internet you'll run into firewalls and nats. So you end up with a third variation where the client initates the connection, and the server leaves the connection open to send information back and forth.

You need to provide a lot more information, are we talking about internet or intranet? What .net framework are you targeting? How many clients are you talking? A solution that can handle a dozen clients (Especially in a push model or the third model) could look very different from a solution which can scale to thousands of clients.

The easiest solution is to do polling from the client side, which unless you want the server to have instant communication to the client is the way to go. And a heart beat is not instant communication.

Edit

Ok you indicated sockets, are you really sure you want to do lower level network type programing? Why not build upon existing network strategies such as HTTP. You can do a simple remoting service over HTTP which will let you bypass firewalls. Or even better if your server is a web server then just setup a plain old xml service.

I don't have any examples I can share of this, but there should be plenty around.