服务器多线程，协议必须？还有更多
假设应用层协议是通过UDP实现的。客户端需要超时，因此服务器需要保留与其通信的每个客户端的状态。
还假设使用了select。
实现多线程服务器总是最好的吗？我认为链接列表也会做同样的事情，其中服务器超时
time=客户端的最早超时 - CurrentTime。链接列表将具有与保留客户端状态相同的功能，同时避免创建新线程的开销（尽管为服务器维护客户端特定的超时引入了一些复杂性）。如果选择多线程，那么接下来，为新客户端调用新套接字是最好的吗？这会引入系统资源开销。但我认为默认的服务器套接字（
bind与服务器众所周知的端口）会做同样的事情，因为它有缓冲区（好吧..对于可扩展的客户端数量来说可能不够长..）
谢谢！
Suppose a application level protocol is implemented via UDP. Client timeout is required, thus server need to keep state of each client it talks to.
Also suppose select is used.
Is it always the best to implement multi-threading server? I figure a link-list will do the same, where server timeout
time=Earliest Timeout of a client- CurrentTime. A link-list will have the same function as keeping client's states, while avoiding the overhead of creating new threads(though introducing some complexity for server to maintain client-specific timeout).If multi-threading is chosen, then onward, is it the best to invoke new socket for new client? This will introduce system resource overhead. But I figure the default server socket (
bindwith server well-known port) will do the same since it got buffer (well..maybe not long enough for scalable num of clients..)
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据我的经验，当可怕的同步问题潜伏着，等待某些事件以正确的顺序发生而导致应用程序崩溃时，线程使您的代码很容易看起来合乎逻辑且干净。线程是一个非常有用的工具 - 如果您的应用程序能够充分利用您的 CPU，您需要考虑线程，并且学习使用线程是学习利用分布式处理的一个步骤（至少，我想是的）。
我的偏好是使用异步回调编写应用程序，而不是阻塞调用，并显式指示我要使用哪个线程来处理回调。这样做有以下优点：
In my experience, threading makes it very easy for your code to look logical and clean, when horrible synchronization issues are lurking, waiting for some events to occur in just the right sequence that the application blows up. Threading is a very useful tool - you need to think with threads if your application is going to be able to take full advantage of your CPU(s), and learning to work with threads is a step towards learning to leverage distributed processing (at least, I think so).
My preference is to write applications using asynchronous callbacks, instead of blocking calls, and explicitly direct which thread I want to use for handling the callback. This has the following advantages:
我不会提出 Aidan Cully 的答案中没有的任何新内容，但是，请看一下 Apache 多处理模块背后的理论：http://www.linuxquestions.org/linux/answers/Networking/Multi_Processing_Module_in_Apache
本质上，服务器被拆分为多个模块，线程/进程被划分为多个模块。创建用于管理连接，具体取决于需要和配置选项 - 这听起来像 Aidan 的答案中描述的平衡，尽管 Apache 实现可能略有不同。
I'm not going to suggest anything new that isn't in the answer by Aidan Cully, however, take a look at the theory behind Apache's Multi Processing Modules: http://www.linuxquestions.org/linux/answers/Networking/Multi_Processing_Module_in_Apache
In essence, the server is split into multiple modules and threads/processes are created to manage connections, depending on need and configuration options - it sounds like the balance described in Aidan's answer although the Apache implementation may differ slightly.
链接列表无法扩展。
对于 5 到 10 个客户端来说，在服务器端使用链表来逐一检查客户端并满足他们的需求是非常好的。但当你有 100 个时会发生什么呢？ 1000？如果一个客户的请求需要很长时间才能处理，会发生什么情况？
线程不仅仅提供了一种为单个客户端维护状态的方法。它们还提供了一种在所有客户端上同时“分配服务器资源”的方法。就好像每个客户端都有一个属于自己的专用服务器，（几乎）没有队列：客户端想要一些东西，它询问服务器，服务器回复。这是瞬时的。
另外，您的链接列表方法可能会浪费宝贵的资源。如果除了一个客户之外的所有客户都什么都不想要怎么办？您将重复循环超过一百个客户端，除了浪费 CPU 周期之外什么也不做，直到遇到确实需要服务器注意的客户端。
Linked-Lists will not scale.
Using linked lists on the server-side to check the clients one-by-one and address their needs is all well and good for 5 to 10 clients. But what happens when you have 100? 1000? What happens if one clients request takes a very long time to handle?
Threads don't just provide a way of maintaing state for individual clients. They also provide a way of simultaneously "distributing the server resources" across all clients. It's as if each client has a dedicated server to itself, there is (almost) no queue: the client wants something, it asks the server, the server replies. It's instantaneous.
Plus, you could be wasting valuable resources with your linked list approach. What if all the clients but one want nothing? You'll be cycling repeatedly over a hundred clients, doing nothing but wasting CPU cycles, until you come across the one that does require the server's attention.
多线程绝对不是必须的，因为您已经想出了替代方案。我们不能真正使用像总是或从不这样的绝对说法，因为每种情况都有独特的要求和约束。
是的，为每个连接添加一个新的线程/套接字会消耗更多的资源。听起来您需要对需要多少连接有一个很好的定义。然后您可以确定您是否拥有足够的资源。
如果不考虑资源限制，我会选择更简单的解决方案。与编写新的功能体（链表建议）相比，使用已有的工具（即经过良好测试的函数来处理线程和套接字）是否更容易？代码维护怎么样？如果将来有另一个程序员从事这个项目，他们是否会更容易理解使用他们已经熟悉的标准操作系统调用或链表的实现？
Multi-threading is definitely not a must as you have already come up with an alternative. We can't really use absolutes like always or never as each case has unique requirements and constraints.
Yes, adding a new thread/socket for each connection will consume more resources. It sounds like you need to get a good definition of how many connections you will need. Then you can determine if you will have sufficient resources or not.
If the resources constraints are not a concern, I would choose the simpler solution. Is it easier to use the tools you already have (i.e. well tested functions to handle threads and sockets) as opposed to writing a new body of functionality (the linked list suggestion)? What about code maintenance? If another programmer works on this project in the future, would it would be easier for them to understand an implementation with standard operating system calls they are already familiar with or a linked list?