我在这里有一个关于.Net框架技术和游戏服务器的问题。假设我有几台游戏机作为客户端,我想把这些游戏机连接到游戏服务器上,你们觉得我用.NET框架开发服务器应用程序好吗?
客户端也采用dotnet技术开发。如果我将我的服务器扩展到几个并发运行的服务器,如果我在我的游戏服务器上使用.Net框架,这是可能的吗?我应该使用什么.Net技术,.Net Remoting,XML web services,COM+,MSMQ还是任何建议?
这里还有一个更重要的因素是性能。我希望客户端和服务器之间的通信能够快速有效地通信,而不会有很长的延迟时间。
我想扩展到几个服务器的目的是因为如果其中一个服务器关闭或关闭维修,我仍然可以让我的应用程序运行,而不中断游戏进程,这是任务关键型和实时的。
以前有没有善良的灵魂做过这样的设置?如果是,你们对此有何感想?在游戏服务器中使用.Net最好、最好、最差还是最差?
我真诚地感谢所有的.Net和游戏开发专家在这里给我一些反馈。
谢谢,
发布于 2010-03-01 12:17:53
为了实现游戏服务器的任何类型的可伸缩性,您需要使用UDP进行通信( .NET支持,请参阅UdpClient)。
本文可能会为您指明正确的方向:Multi-Threaded Game Server Browser
发布于 2010-03-01 12:19:33
我不确定标准的.Net方法会不会是你想要的方式……
你提到的每一种.Net技术都有一个可衡量的安装和拆卸成本,并且是其中最糟糕的。如果性能是您的目标,那么您需要直接与端口对话,而不是使用标准化的包装器来处理它们。我甚至认为,如果性能真的很关键,那么您需要考虑直接的C函数,而不是.Net语言。(有些人肯定不同意我的观点,但我发现像Ruby和Python这样的动态语言也非常快)
另一个起作用的问题是你的数据后端。如果所有数据都在内存中,那么运行多个服务器意味着您必须采用某种缓存机制,如memcached来保持数据同步。如果您要使用数据库,我建议您使用多个端口,一个端口连接到数据库,另一个端口严格基于内存。您获得的优势是,不需要数据库的数据可以在内存空间中运行,该内存空间的运行速度与计算机运行的速度一样快,并且进程不必等待代价高昂的数据库连接。
WCF/.Net Remoting/COM+/等对于业务线应用程序来说都很棒,在这些应用程序中,1秒的周转时间不会杀死你,但在每一毫秒都很重要的实时环境中,你需要能够管理从收到第一个数据包到关闭连接的整个通信堆栈。我在实时环境中使用的每个.Net通信堆栈都为每个请求增加了近100ms。通过省去中间人并直接与客户端打交道(例如,直接从端口读取流,然后将流直接发送到端口),我削减了成本并收回了时间。当您每分钟处理数万个请求时,这段时间就变得非常重要。
发布于 2010-03-01 11:39:46
我不认为我有回答这个问题所需的领域知识,但我还是想试一试,也许我会问一些问题,帮助你梳理出正确的答案。
.Net是一条可行的道路吗?我不知道。和DirectX沟通吗,-通过了,抱歉
客户端和服务器是否在同一个LAN上?他们是通过网络连接的吗?为了更好的性能,我使用了ssume .Net Remoting。对于一般的通信,您可能想要考虑WCF,因为您可以通过更改配置(例如,对web服务进行排队)来很大程度上改变通信方式。话虽如此,为了最大限度地利用排队之类的东西,您可能需要小心实际设计端点的方式。
您谈到了向外扩展服务器?我猜你会想要使用某种类型的负载均衡器,下面有多个节点?这可能会有帮助:http://www.codeproject.com/KB/IP/remotingdesigndecisions.aspx
https://stackoverflow.com/questions/2353703
复制相似问题