Problème lors de la création de l'application de salle de chat

Question

J'essaie de créer une application de type salle de discussion pour un site Web. Pour cela, j'ai deux options:

1. Pour utiliser la programmation socket et ouvrir une socket au serveur et le connecter à tous les clients qui sont dans cette salle de chat. pour ce client, téléchargez d'abord l'applet du salon de discussion.

2. juste pour envoyer des demandes au serveur avec Ajax en continu avec un intervalle de 1 seconde et rafraîchir la zone de contenu de discussion de la page.

Je ne peux pas décider quel stretagy sera meilleur. Donc, si quelqu'un me dit lequel sera moins gourmand en ressources et s'il y a encore d'autres options, dites-le moi s'il vous plaît.

Deuxièmement, je pensais utiliser le fichier de session stocké sur le serveur qui maintient toutes les sessions de l'utilisateur connecté. Alors, comment dois-je accéder à ce fichier stocké sur le serveur afin que je puisse avoir une variable membre de l'objet de session comme

sessionobject.chatroom="1". // S'il vous plaît ne pas aller à la syntaxe, mais sur sa signification.

Est-il possible d'accéder au fichier créé par le serveur sur le serveur pour la maintenance des sessions? et si oui alors comment?

Answer 1

Pour le côté client, je voudrais jeter un oeil à Comet, qui est le terme technologique pour effectuer une poussée côté serveur à un navigateur. Il existe un certain nombre de méthodes que vous pouvez consulter pour exécuter cette fonctionnalité, dont deux que vous avez mentionnées (socket long et interrogation). Ces deux techniques peuvent être effectuées en utilisant CometD qui est une bibliothèque JavaScript construite par la fondation Dojo en utilisant la spécification Bayeux. En ce qui concerne la détermination de l'approche qui est la meilleure, vous devez examiner votre infrastructure.

Un grand nombre de serveurs sont limités par le nombre de threads de traitement et ne peuvent gérer qu'un certain nombre de sockets entrants en même temps. Une fois que vous atteignez la limite, toutes les autres sockets seront mises en file d'attente (ou supprimées selon le serveur) jusqu'à ce que les sockets aient été libérées. Tomcat6, ainsi que d'autres serveurs plus récents, prennent en charge l'utilisation des API NIO, ce qui permet un traitement de socket client non bloquant, ce qui supprime les restrictions sur les connexions de socket entrantes. Si vous avez un serveur Web, un pare-feu, un proxy, un équilibreur de charge, etc. entre le client et vous-même qui a une limite de socket, vous devrez en tenir compte dans votre solution finale. Cette approche fonctionne très bien si votre infrastructure peut la prendre en charge, car elle offre à vos clients le temps de réponse le plus court et réduit le coût de configuration et de retrait des sockets. L'inconvénient, comme mentionné, est que votre infrastructure devrait prendre en charge votre nombre maximum d'utilisateurs attendus (le support inclut des descripteurs de fichiers, etc.). La méthode alternative d'utilisation de l'interrogation: tout en ajoutant plus de temps système et un temps de réponse plus lent parce qu'elle n'est pas toujours connectée, a l'avantage de permettre à votre serveur d'utiliser moins de ressources pour prendre en charge le même nombre d'utilisateurs. , etc...). En ce qui concerne votre deuxième question, je ne suis pas vraiment sûr de ce que vous demandez. Si vous essayez d'accéder à des informations dans la session d'un utilisateur en dehors d'une requête générée par cet utilisateur, cela n'est pas autorisé par la spécification et serait considéré comme une violation de sécurité. Si vous parlez de stocker et d'accéder aux informations dans la session d'un utilisateur lors d'une requête par cet utilisateur, cela est possible en utilisant les API HttpSession standard. Je vous recommande de ne pas utiliser ou essayer d'utiliser la première approche car ce n'est pas un bon design.Si vous devez gérer des données utilisateur qui doivent être accessibles par tous les threads utilisateur, vous devez conserver ces données externes à la session d'un utilisateur individuel (base de données, fichier, etc.).

Espérons que cela aide.