我在这里有关于.Net框架技术和游戏服务器的问题。假设我有一些游戏机充当客户端，我想将这些客户端机器连接到游戏服务器，你们认为如果我使用.NET框架开发服务器应用程序是好的吗？
客户机也是用dotnet技术开发的。如果我将我的服务器扩展到几个同时运行的服务器，如果我在我的游戏服务器上使用.Net框架，那该怎么办？我应该使用什么.Net技术，.Net Remoting，XML Web服务，COM +，MSMQ或任何建议？
这里更重要的一个因素是表现明智。我希望客户端和服务器之间的通信能够快速有效地进行通信而不会长时间滞后。
我想扩展到几个服务器的目的是因为如果其中一个服务器关闭或关闭进行服务，我仍然可以让我的应用程序运行而不会中断任务关键和实时的游戏过程。 / p>
之前有什么样的灵魂做过这样的设置吗？如果是的话，你们对此感觉如何？在游戏服务器中使用.Net的最佳，好，差或最差？
我真诚地感谢.Net和游戏开发专家在这里为我提供一些反馈。
感谢，
答案 0 :(得分：1)
为了获得游戏服务器的任何可扩展性，您需要利用UDP进行通信（.NET支持，请参阅UdpClient）。
本文可能会指出您正确的方向：Multi-Threaded Game Server Browser
答案 1 :(得分：1)
我不确定标准.Net方法是否会成为你想要的方式......
您提到的每种.Net技术都具有可衡量的设置和拆卸成本，而WCF是最糟糕的。如果性能是您的目标，则需要直接与端口通信，而不是使用标准化的包装器来处理它们。我甚至认为，如果性能真的是关键，你需要看一个直接的C函数而不是.Net语言。 （有些人肯定不同意我的看法，但我发现像Ruby和Python这样的动态语言也非常快速）
将要发挥作用的另一个问题是数据后端。如果它全部在内存中，则运行多个服务器意味着您将不得不采用某种缓存机制（如memcached）来保持数据全部同步。如果您打算使用数据库，我建议使用几个端口，一个连接到您的数据库，另一个严格基于内存。您获得的优势是，不需要数据库的数据可以在运行速度与计算机运行速度相同的内存空间中运行，并且该过程不必等待昂贵的数据库连接。
WCF / .Net Remoting / COM + /等对于业务应用程序来说非常适用，其中1秒的周转时间不会让您失望，但在实时环境中，每毫秒计数您需要能够管理从收到第一个数据包到关闭连接之间的整个通信堆栈。我在实时环境中使用的每个.Net通信堆栈都为每个请求增加了近100毫秒。通过切断中间人并直接与客户交易（即，直接从端口读取流然后将流直接发送到端口），我减少了成本并将时间缩短了。当你每分钟处理成千上万的请求时，这个时间变得非常重要。
答案 2 :(得分：0)
我认为我不具备回答这个问题所需的那种领域知识，但我还想试一试，也许我会问一些问题，这些问题有助于为你找到合适的答案。
.Net还有可行吗？我不知道。与DirectX通信？ - 通过，抱歉。
客户端和服务器是否在同一个LAN上？他们是通过网络连接的吗？ 对于纯粹的表现，我想要一个ssume .Net Remoting。对于一般的通信，您可能需要考虑WCF，因为您可以通过更改配置（例如，排队到Web服务）来改变您的通信方式。话虽如此，为了最大限度地排除排队等问题，您可能需要小心实际设计端点。
您谈到扩展服务器？我想你会想要某种负载均衡器，其下有多个节点？ 这可能会有所帮助：http://www.codeproject.com/KB/IP/remotingdesigndecisions.aspx