3

目前我正计划用 C# 为 XNA 游戏设计一个专用服务器，最多可以同时连接 32 名玩家。我有过使用 System.Net 联网的经验，但我以前不必处理大量玩家。

我从心里知道创建和销毁线程（尤其是为每个玩家创建一个线程）不是一个好主意，而且我不确定是否使用线程池，因为“没有线程可用时排队等待”自然。因此，我决定（几乎是我唯一的最后一个选择）使用 Async 来处理大量客户端。

但是我仍然不确定这是否是一个明智的选择，或者我是否应该使用其他东西来满足我苛刻的需求。

如果这个问题听起来很黯淡，我很抱歉，但我很困惑 - 非常感谢帮助！

4

3 回答 3

3

如果游戏的限制确实是 32 个并发用户，并且可能只有少数观察者，那么线程就可以了，特别是如果你发现它们比回调更容易编写代码。（您必须适当地协调对共享数据结构的访问，其复杂性可能超过相应的基于事件的设计。）

我什至可能不会为只有 32 个并发用户的线程池而烦恼。

吞吐量的线程限制显示大约 100 个线程（当然取决于实现细节）。如果您从不打算同时拥有 100 个用户（例如，这将是一个负载非常轻的 IRC 服务器），那么除非您和您的团队更容易使用事件模型，否则就不需要异步事件模型。

于 2012-01-21T01:27:01.533 回答
2

当服务器受 I/O 限制时，异步方法很强大。等待 I/O 时将需要更少的资源。

当服务器受 CPU 限制时，线程方法很强大。它可以轻松扩展到多个内核或 CPU。

对于 32 个用户，我会谨慎地建议使用线程，至少在 .NET 中的黄金时间准备好异步支持之前。只需使用 .NET 中包含的线程安全结构进行所有线程间通信，不要编写自己的代码，应该没问题。如果您决定自己编写代码，经验告诉我，您的情况可能会更糟，因为即使是最轻微的错误也可能导致非常难以追踪的随机错误。

于 2012-01-21T01:37:30.813 回答
0

适合您的取决于您计划的负载。性能最高的解决方案通常被认为是异步处理器的线程池，但这很容易被严重矫枉过正。选择可以完成这项工作的最简单的解决方案。

于 2012-01-21T01:24:45.547 回答