How To Structure A Web/Client Support Chat System

I am looking to build an online customer support system for one of our company sites and had a few queries with regards to the structuring.

The scenario is this. We would like users of our site to be able to click a "Live Chat Support" button, at which point they开发者_如何学Go would get a popup that tries to connect them to one of our support team.

Our support team on the other hand, will be running desktop clients. Whenever a user on our site clicks the link, all of the desktop clients will "ring". Whenever a support team member "answers" the call, the other clients will stop ringing and that member will begin chatting with the web user.

Given that our desktop client will be made using WPF in C#.NET and our site is ASP.NET MVC 2 - what would be the best way to establish communication between the two?

My initial thoughts were to have the web side store the chat in an SQL database and somehow "Ping" the relevent desktop client telling it to update its chat log. Similarly for the desktop to the web. But I am unsure how to go about implement this between two different platforms. If it were desktop client to desktop client I imagine it would much easier, but this is not the case.

Also, please bare in mind that I realise there are already commercial applications out there that do this. However, we require some bespoke functionality that goes beyond a simple chat - it is not worth going into the specifics but basically we must implement our own solution.

Any help is much appreciated.

---

Web technology is an inappropriate platform for implementing real-time interaction. It can be done, of course, but you will certainly have issues with scalability, responsiveness and development effort. I urge you to examine your requirements very carefully and consider whether it is at all possible to leverage a vendor product to accomplish what you want to do.

If you still want to strike out on your own, the main hurdle you will have to overcome is how to push messages to the browser. "Pinging" the browser from the server is impossible using pure web technologies, because HTTP is built on a "pull-only" request/response model. There is no persistent connection maintained between the client in the server. After the server has finished sending the page to the broswer, the connection is gone.

You could poll the web server for new messages, but this is not a scalable solution. If you're only dealing with a very small (say single digits) number of users, then this might work, but your responsiveness will be limited by the speed at which you poll, and the faster you poll, the less scalable this solution will be.

A better solution would be to use Silverlight, Flash, or some other thick-client technology running in the browser. Then you could implement a service that handles message routing between clients. This article on CodeProject might be a good place to start.