多个聊天室 - 使用端口是唯一的方法吗？如果有数百个房间怎么办？
需要一些关于这方面的指导。 我正在编写一个聊天室浏览器应用程序，但是有一个细微的差别。
这些是协作聊天，其中一个人打字，另一个人可以实时另一个人在打字时输入的任何击键。
此外，聊天空间不是一行，而是一个文本区域空间，就像这里输入问题的空间（SO）一样。
所有击键（包括制表符/空格/回车）都应该对其他人实时可见。而且一次只有一个人可以打字（我想锁定应该是微不足道的）
我还没有编写多聊天室应用程序。我编写了一个简单的客户端/服务器，其中两者都通过端口进行通信。
这是问题
1.) 多聊天室应用程序是如何编写的？它也是基于端口的吗？
2.）我想通过ajax可以向其他人显示他们打字时的每一次击键。还有其他可用的机制吗？
注意：我将使用 python 框架（web2py），但我认为框架在这里并不重要。
欢迎任何建议，谢谢！
Need some direction on this.
I'm writing a chat room browser-application, however there is a subtle difference.
These are collaboration chats where one person types and the other person can see live ever keystroke entered by the other person as they type.
Also the the chat space is not a single line but a textarea space, like the one here (SO) to enter a question.
All keystrokes including tabs/spaces/enter should be visible live to the other person. And only one person can type at one time (I guess locking should be trivial)
I haven't written a multiple chatroom application. A simple client/server where both are communicatiing over a port is something I've written.
So here are the questions
1.) How is a multiple chatroom application written ? Is it also port based ?
2.) Showing the other persons every keystroke as they type is I guess possible through ajax. Is there any other mechanism available ?
Note : I'm going to use a python framework (web2py) but I don't think framework would matter here.
Any suggestions are welcome, thanks !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
发布评论
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
Comet（编程） 的 Wikipedia 条目对不同的您可以在客户端上采取的方法（假设您的客户端是 Web 浏览器），并且这些方法建议服务器的正确设计（假设服务器是 Web 服务器）。
该页面上没有提到但您几乎肯定会想要考虑的一件事是缓冲客户端上的输入。我不认为考虑到每个用户的击键都会影响服务器的多用户应用程序的扩展性会很差，这是不成熟的优化。我会考虑让用户击键进入客户端缓冲区，并且仅当用户在 500 毫秒左右没有键入任何内容时才将它们发送到服务器。
您绝对不想为此使用端口。这将应用程序层信息放入传输层，并将应用程序级问题（应用程序将创建一个新的聊天室）推入传输级问题（需要在防火墙上打开一个新端口）。
此外，端口只是数据包标头中的一个 16 位字段。您可以在应用程序消息的设计中执行相同的操作：在每条消息的开头放置房间 ID 和用户 ID，然后让服务器将其全部排序。
让我感到痛苦的是弄清楚当客户端请求更新时应该发送什么。最简单的解决方案是为房间中的每个用户保留一个缓冲区，并维护每个（其他）用户缓冲区的索引作为用户状态的一部分；这样，当用户 A 请求更新时，服务器可以发送自 A 上次请求以来用户 B、C 和 D 键入的所有内容。这引发了有关内存使用和持久性的各种问题，这些问题没有明显的简单解决方案。
我在这里讨论的问题的正确答案将取决于您的需求。确保详细定义这些要求。您不想发现自己提出诸如“我应该将击键组合在一起吗？”之类的问题。当你建造这个东西的时候。
The Wikipedia entry for Comet (programming) has a pretty good overview of different approaches you can take on the client (assuming that your client's a web browser), and those approaches suggest the proper design for the server (assuming that the server's a web server).
One thing that's not mentioned on that page, but that you're almost certainly going to want to think about, is buffering input on the client. I don't think it's premature optimization to consider that a multi-user application in which every user's keystroke hits the server is going to scale poorly. I'd consider having user keystrokes go into a client-side buffer, and only sending them to the server when the user hasn't typed anything for 500 milliseconds or so.
You absolutely don't want to use ports for this. That's putting application-layer information in the transport layer, and it pushes application-level concerns (the application's going to create a new chat room) into transport-level concerns (a new port needs to be opened on the firewall).
Besides, a port's just a 16-bit field in the packet header. You can do the same thing in the design of your application's messages: put a room ID and a user ID at the start of each message, and have the server sort it all out.
The thing that strikes me as a pain about this is figuring out, when a client requests an update, what should be sent. The naive solution is to retain a buffer for each user in a room, and maintain an index into each (other) user's buffer as part of the user state; that way, when user A requests an update, the server can send down everything that users B, C, and D have typed since A's last request. This raises all kind of issues about memory usage and persistence that don't have obvious simple solutions
The right answers to the problems I've discussed here are going to depend on your requirements. Make sure those requirements are defined in great detail. You don't want to find yourself asking questions like "should I batch together keystrokes?" while you're building this thing.