假设应用层协议(protocol)是通过UDP实现的。客户端需要超时，因此服务器需要保留与其通信的每个客户端的状态。
还假设使用了select。
实现多线程服务器总是最好的吗？我认为链接列表也会做同样的事情，其中服务器超时
time=客户端的最早超时 - CurrentTime。链接列表具有与保留客户端状态相同的功能，同时避免创建新线程的开销(尽管为服务器维护特定于客户端的超时引入了一些复杂性)。如果选择多线程，那么接下来，为新客户端调用新套接字是最好的吗？这会引入系统资源开销。但我认为默认的服务器套接字(
bind与服务器众所周知的端口)会做同样的事情，因为它有缓冲区(好吧..对于可扩展的客户端数量来说可能不够长..)
谢谢!
最佳答案
根据我的经验，当可怕的同步问题潜伏着，等待某些事件以正确的顺序发生而导致应用程序崩溃时，线程使您的代码很容易看起来合乎逻辑且干净。线程是一个非常有用的工具 - 如果您的应用程序能够充分利用您的 CPU，您需要考虑线程，并且学习使用线程是学习利用分布式处理的一个步骤(至少，我想是的)。
我的偏好是使用异步回调编写应用程序，而不是阻塞调用，并显式指示我要使用哪个线程来处理回调。这样做有以下优点:
- 它使状态变量交互更加可控，因此可预测，这意味着线程更加稳健。
- 如果做得正确，它可以充分利用 CPU 拥有的处理器数量。
- 它允许您直接控制要赋予某些函数的优先级 - 如果该函数具有高优先级，则将其分派(dispatch)给高优先级线程，然后当它完成时，它会发送结果通过调用者线程中的延续返回到低优先级调用者。或者到另一个线程 - 没有理由限制它。
- 通常可以移植到非线程环境。也许对大多数人来说并不重要，但有时对我来说很重要。
关于c - 服务器多线程，协议(protocol)必须？和更多，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2163490/