2010-01-15 7 views
8

Je dois programmer des sites Web, mais je n'aime pas la nature HTML statique. Je préfère plus d'une architecture client-serveur. Maintenant, j'ai pensé que, avec XMLhttp, vous pouvez fondamentalement mettre à jour dynamiquement votre page et envoyer/demander des informations/actions à/d'un serveur. Donc, cela couvrirait essentiellement la zone client. Mais pour compléter une architecture client-serveur, il est également nécessaire que le serveur envoie/demande des informations sans être interrogé.AJAX et architecture client-serveur avec JavaScript

Est-il possible, par exemple pour un serveur de chat, de renvoyer un message reçu à tous les clients (les clients utilisent un navigateur Web) sans que les clients doivent interroger dans un intervalle fixe? Je veux mettre en œuvre que l'on peut voir pendant que vous tapez quelque chose.

+0

Vous parlez d'une opération "Push" du serveur Web, plutôt que de demander au code client de demander un nouveau code, n'est-ce pas? –

+0

Correct! Je souhaite émettre une commande de serveur qui déclenche une action client. –

Répondre

13

Il y a plusieurs façons d'y parvenir. Certains d'entre eux ont déjà répondu ici, mais je voulais en inclure quelques autres ainsi que mes pensées sur eux.

1.Relève

Des demandes fréquentes sont effectuées sur le serveur pour vérifier les nouvelles informations. C'est le pire moyen de le faire, mais probablement le plus facile. Si votre site a un nombre d'utilisateurs faible, cela peut valoir la peine de le faire de cette façon. Cela peut être accompli en utilisant setInterval(myFunction, n) en javascript pour envoyer XMLHttpRequests au serveur tous les n millisecondes. Ensuite, sur le serveur, vous répondez à cela avec vos nouvelles informations, quand vous l'avez, ou un message qui n'implique aucune nouvelle information.

2. longue interrogation

Lorsque la page est chargée, il fait une demande au serveur pour de nouvelles informations. Le serveur maintient la connexion ouverte jusqu'à ce qu'il y ait quelque chose à renvoyer. Cette méthode réduit la quantité de trafic réseau utilisée, mais augmente les ressources utilisées sur le serveur. Vous pouvez l'utiliser pour un petit nombre d'utilisateurs, mais cela ne fonctionne pas très bien. La méthode la plus simple consiste à demander à la page qui gère la requête AJAX d'attendre simplement que de nouvelles informations soient disponibles, puis de répondre. Cela peut bloquer beaucoup de connexions sur votre serveur. Donc, utilisez avec soin.

3. COMET

COMET est essentiellement longue interrogation, mais le serveur est configuré correctement pour elle. Il sait que ces connexions ne sont pas "réelles" et utilise moins de ressources pour les gérer. C'est une excellente solution pour ce problème, mais cela nécessite que le serveur soit configuré explicitement à cette fin. Il y a des serveurs COMET et des add-ons COMET pour d'autres serveurs populaires, mais il faudra une certaine configuration et parfois de l'argent. L'implémentation sur .NET n'est pas la chose la plus simple au monde. Vous pouvez payer pour des solutions, essayer de trouver le code de quelqu'un d'autre qui fait quelque chose de similaire ou essayer de l'écrire vous-même. Je n'ai trouvé aucune solution libre décente pour cela. Si quelqu'un d'autre a, s'il vous plaît commenter.

4. RIA

Une autre solution serait d'inclure Flash, Silverlight ou Java Applet sur votre page. Les gens le font souvent en utilisant un objet 1x1 afin qu'ils puissent utiliser Flash ou Silverlight pour parler au serveur. Si cela ne vous dérange pas d'ajouter la dépendance, c'est une solution décente. Si vous connaissez déjà Silverlight ou Flash, cela pourrait être relativement simple à implémenter.

Vous trouverez des didacticiels sur Internet pour chacune de ces options.

5. Prises Web

Si vous êtes sur le bord de coupe, vous pouvez regarder dans Web Sockets. Il est uniquement disponible dans les dernières versions des navigateurs modernes. Il faisait partie de HTML5, mais il pourrait être sa propre spécification maintenant. Quoi qu'il en soit, cela signifie que les anciens navigateurs ne seront pas en mesure de le gérer. Mais, si cela ne vous dérange pas de vous limiter aux derniers navigateurs, vous pouvez utiliser cette fonctionnalité incroyable.

Je crois que Chromium est le seul navigateur qui le supporte actuellement. Cependant, des travaux sont en cours pour l'implémenter dans Firefox et WebKit.

Je vais vous épargner la controverse et dire simplement que cela fait exactement ce que vous voulez. Le résumé de la spécification dit tout.

Cette spécification définit une API qui permet aux pages Web d'utiliser le protocole Web Sockets pour une communication bidirectionnelle avec un hôte distant.

Mention spéciale

Si vous êtes intéressé par le monde du nœud JS, vous ne pouvez pas vous tromper avec Socket IO. Il mettra en œuvre le meilleur de la technologie disponible pour le navigateur.

Conclusion

La meilleure option est Socket.IO sur le nœud JS. Toutefois, pour une solution ASP.Net, optez pour COMET ou Web Sockets, si vous le pouvez. Sinon, l'utilisation de Flash/Silverlight n'est pas terrible. Enfin, les sondages et les longs scrutins devraient être les derniers recours. Vous pouvez toujours prendre en charge l'un d'eux, puis revenir à un autre s'il n'y a pas de support dans le navigateur du client.

+1

Après un examen attentif, j'ai choisi WebSockets + WebSockets-FlashBridge, pour non-Chromium. Cette combinaison fonctionne bien pour tous les navigateurs, y compris iPhone + iPad. –

1

Le client doit indiquer au serveur quand le client commence à taper. Vous avez quelques options ici.

  1. Requêtes fréquentes du serveur pour la dernière activité. Cela aurait lieu pour chaque utilisateur impliqué dans le chat. La même requête peut également être utilisée pour envoyer une activité spécifique au serveur: "Jonathan tape ..."

  2. Recherche longue. Cela demande essentiellement des informations du serveur, et le serveur maintient la connexion ouverte jusqu'à ce qu'il ait quelque chose à renvoyer. Vos requêtes sont donc minimisées, mais vos connexions restent ouvertes plus longtemps.

En fonction de votre trafic, du type de données transmises, de l'environnement du serveur et de bien d'autres facteurs, l'une de ces options peut briller plus que l'autre.

0

Basé sur l'architecture REST sur laquelle le système html est basé, le rôle des serveurs consiste simplement à agir comme une ressource à partir de laquelle le client peut tirer. Je généralise mais il y a des outils pour implémenter ce type d'action côté client plutôt que côté serveur.

Il est préférable d'écrire/d'utiliser une bibliothèque qui peut demander des mises à jour périodiquement au serveur. Vous pouvez encapsuler ces types de demandes dans un objet javascript pouvant déclencher des événements. De cette façon, votre script côté client peut agir comme s'il était averti par le serveur. Passez en revue quelques trucs communs avec COMET vous pouvez probablement trouver quelques outils pour vous aider le code côté client.

HTML 5 propose quelques tentatives de ce type de fonctionnalité, mais si vous souhaitez que votre application fonctionne sur des navigateurs plus anciens, mieux vaut utiliser des méthodes plus stables, comme les mises à jour demandées par AJAX.