这是我经历过的几次，经过短暂的休息后，我回来了一个客户端的应用程序，但只是想在实际实现之前记住一些事情。
我将在这里讨论一个多客户端服务器，它处理通过TCP连接到服务器绑定端口的客户端。
我记得通过使用select（），FD_ISSET，FD_ZERO，FD_SET来编码这个 - 它是家庭方法来接受和管理我服务器上已连接客户端的列表 - 我记得它工作得很好，但这一次是关于一个简单的32人RPG游戏 - 所以没有快节奏，因此TCP在这里。
简单的GO_TO数据包，天气变化，时间更新，TEXT消息，项目状态更改和退出，登录（广播）以及我现在无法找到的其他内容。
阻止我今天睡觉的是我应该选择让这台服务器顺利运行（当谈到它的网络性能时）。
人们倾向于通过使用ioctlsocket（..）或其他一些'线程'怪人来谈论套接字的'非阻塞'方法，这样做但你必须以不同的方式控制它们 - 是的我试过这个，并且已经看到了很多方法 - 它们处理应用程序中的许多线程 - 实际上是什么样的复杂...
我也看过那些MSDN“ASYNCHROUNOUS”套接字，你从套接字那里得到消息 - 但是我认为这太多了。
所以不是编码而是我在想，想问一下，
如果select（）在谈到游戏服务器时可以做到这一点，那么就可以同时处理这32个玩家。我在这里的意思是你如何根据自己的经验思考，那会做什么？或者我必须在最后回滚并在截止日期前修改整个服务器代码..
执行select / ioctlsocket之间究竟有什么区别？
这两种方法的优缺点是什么？
非常感谢对此的任何回复，我希望我能清楚地了解我的问题。
答案 0 :(得分：1)
如果你真的认真考虑在C ++中使用更高级的网络内容，你最终应该考虑使用boost::asio，一旦你理解了它的哲学，就没有什么“过于复杂”了。拥有32名玩家的支持最终会让你陷入线程的束缚，所以为什么不从今天开始呢？
同样重要的是在游戏等待网络输入时处理死连接，无响应客户端以及游戏状态的任何更新的问题。你打算如何解决这个问题？
答案 1 :(得分：1)
select-style服务器可以轻松处理少量并发客户端，即使是在适度的硬件上也是如此。
首先考虑可读性，并根据您的经验选择最简单的解决方案。如果您在过去使用select做过类似的实现，那么不要担心性能。
根据我的阻断IO的经验，在第一次尝试时更难以正确，然后是选择方式，但您的里程可能会有所不同。