Comment structurer un système de chat de support Web/client

Question

Je cherche à construire un système de support client en ligne pour l'un de nos sites d'entreprise et j'ai eu quelques questions concernant la structuration.

Le scénario est le suivant. Nous souhaitons que les utilisateurs de notre site puissent cliquer sur un bouton "Live Chat Support", auquel cas ils recevront une fenêtre contextuelle qui tentera de les connecter à l'une de nos équipes d'assistance. D'autre part, notre équipe de support exécutera des clients de bureau. Chaque fois qu'un utilisateur sur notre site clique sur le lien, tous les clients de bureau vont "sonner". Chaque fois qu'un membre de l'équipe de support "répond" à l'appel, les autres clients cessent de sonner et ce membre commence à discuter avec l'internaute. Étant donné que notre client de bureau sera fait en utilisant WPF dans C# .NET et notre site est ASP.NET MVC 2 - quelle serait la meilleure façon d'établir la communication entre les deux? Mes pensées initiales étaient que le côté Web stocke le chat dans une base de données SQL et en quelque sorte "Ping" le client de bureau relevent lui disant de mettre à jour son journal de chat. De même pour le bureau sur le web. Mais je ne sais pas comment procéder pour mettre en œuvre cela entre deux plates-formes différentes. Si c'était client de bureau pour le client de bureau, j'imagine que ce serait beaucoup plus facile, mais ce n'est pas le cas.

En outre, s'il vous plaît garder à l'esprit que je me rends compte qu'il existe déjà des applications commerciales qui le font. Cependant, nous avons besoin de fonctionnalités sur mesure qui vont au-delà d'une simple conversation - cela ne vaut pas la peine d'entrer dans les détails mais, fondamentalement, nous devons mettre en œuvre notre propre solution.

Toute aide est très appréciée.

Answer 1

La technologie Web est une plate-forme inappropriée pour mettre en œuvre une interaction en temps réel. Cela peut être fait, bien sûr, mais vous aurez certainement des problèmes d'évolutivité, de réactivité et d'efforts de développement. Je vous invite à examiner attentivement vos exigences et à déterminer s'il est tout à fait possible de tirer parti d'un produit du fournisseur pour accomplir ce que vous voulez faire.

Si vous voulez toujours vous débrouiller seul, le principal obstacle que vous devrez surmonter est de savoir comment envoyer des messages au navigateur. "Ping" le navigateur du serveur est impossible en utilisant des technologies web pures, parce que HTTP est construit sur un modèle de requête/réponse "pull-only". Aucune connexion persistante n'est maintenue entre le client sur le serveur. Une fois que le serveur a envoyé la page au broswer, la connexion est terminée.

Vous pouvez interroger le serveur Web à la recherche de nouveaux messages, mais il ne s'agit pas d'une solution évolutive. Si vous ne traitez qu'un très petit nombre d'utilisateurs (disons à un chiffre), cela peut fonctionner, mais votre rapidité de réponse sera limitée par la rapidité avec laquelle vous interrogez, et plus vite vous serez sondé, moins cette solution sera évolutive. être.

Une meilleure solution consisterait à utiliser Silverlight, Flash ou toute autre technologie client lourd fonctionnant dans le navigateur. Ensuite, vous pouvez implémenter un service qui gère le routage des messages entre les clients. This article on CodeProject pourrait être un bon point de départ.