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

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.

Answer 2

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.