Salles de chat multiples - L'utilisation de ports est-elle la seule solution ? Que faire s'il y a des centaines de salles ?

Question

J'ai besoin de conseils. J'écris une application de navigateur de salon de discussion, mais il y a une différence subtile.

Il s'agit de chats collaboratifs où une personne tape et où l'autre personne peut voir live chaque frappe de clavier effectuée par l'autre personne pendant qu'elle tape. .

De plus, l'espace de discussion n'est pas une ligne unique mais un espace de texte, comme celui qui est proposé ici (SO) pour saisir une question.

Toutes les frappes au clavier, y compris les tabulations/espaces/entrée, doivent être visibles en direct par l'autre personne. Et une seule personne peut taper à la fois (je suppose que le verrouillage devrait être trivial).

Je n'ai pas écrit une application de chatroom multiple. J'ai écrit une simple application client/serveur où les deux communiquent sur un port.

Voici donc les questions
1.) Comment une application de chatroom multiple est-elle écrite ? Est-elle également basée sur le port ?
2.) Montrer à l'autre personne toutes les frappes au fur et à mesure qu'elle tape est, je suppose, possible par ajax. Y a-t-il un autre mécanisme disponible ?

Note : Je vais utiliser un framework python (web2py) mais je ne pense pas que le framework soit important ici.

Toute suggestion est la bienvenue, merci !

Answer 1

Vous pourriez essayer de faire quelque chose comme IRC, où la "salle" actuelle est envoyée du client au serveur "avant" le texte ( /PRIVMSG #room-name Hello World ), délimités par un espace. Par exemple, vous pouvez envoyer ROOMNAME Sample text du navigateur au serveur.

L'utilisation d'AJAX serait l'option la plus raisonnable. Je n'ai jamais utilisé web2py, mais je suppose que vous pourriez simplement utiliser JSON pour analyser les données entre le navigateur et le serveur, si vous voulez être fantaisiste.

Answer 2

L'entrée Wikipedia pour Comète (programmation) offre une bonne vue d'ensemble des différentes approches que vous pouvez adopter sur le client (en supposant que votre client est un navigateur web), et ces approches suggèrent la conception appropriée pour le serveur (en supposant que le serveur est un serveur web).

Une chose qui n'est pas mentionnée sur cette page, mais à laquelle vous voudrez certainement penser, est la mise en mémoire tampon des entrées sur le client. Je ne pense pas qu'il soit prématuré d'envisager l'optimisation d'une application multi-utilisateurs dans laquelle chaque frappe de l'utilisateur est transmise au serveur. J'envisagerais de placer les frappes de l'utilisateur dans un tampon côté client et de ne les envoyer au serveur que lorsque l'utilisateur n'a rien tapé pendant environ 500 millisecondes.

Vous ne voulez absolument pas utiliser les ports pour cela. Cela revient à placer les informations de la couche application dans la couche transport, et cela pousse les préoccupations au niveau de l'application (l'application va créer un nouveau salon de discussion) vers les préoccupations au niveau du transport (un nouveau port doit être ouvert sur le pare-feu).

De plus, un port est juste un champ de 16 bits dans l'en-tête du paquet. Vous pouvez faire la même chose dans la conception des messages de votre application : mettez un identifiant de salle et un identifiant d'utilisateur au début de chaque message, et laissez le serveur faire le tri.

Ce qui me semble pénible dans tout cela, c'est de déterminer, lorsqu'un client demande une mise à jour, ce qui doit être envoyé. La solution naïve est de conserver un tampon pour chaque utilisateur dans une salle, et de maintenir un index dans le tampon de chaque (autre) utilisateur comme faisant partie de l'état de l'utilisateur ; de cette façon, lorsque l'utilisateur A demande une mise à jour, le serveur peut envoyer tout ce que les utilisateurs B, C, et D ont tapé depuis la dernière demande de A. Cela soulève toutes sortes de questions sur l'utilisation de la mémoire et la persistance qui n'ont pas de solutions simples évidentes.

Les bonnes réponses aux problèmes que j'ai abordés ici vont dépendre de vos besoins. Assurez-vous que ces besoins sont définis de manière très détaillée. Vous ne voulez pas vous retrouver à vous poser des questions telles que "dois-je regrouper les frappes de touches ?" pendant que vous construisez cet appareil.