最近想做一个类似联众的网络游戏,就像扑克牌,关于server端程序的设计,特别是网络通信方面的,一直还没有拿定主意。一般做法是对每一个客户端通信,服务器端通过accept()产生一个socket ,然后为这个启动一个线程来管理这个socket的通信。
但是游戏程序一般都有大量的连接,比如3000人,如果给3000个连接每人配一个线程的话就有3000个线程,不知道系统地效率会怎么样? 而且似乎这样对处理复杂的服务器端的业务逻辑的处理似乎也造成了麻烦,总觉得有些不自然。
我的想法是给每一桌游戏创建一个线程,这样如果一桌游戏有4个人的话,那样线程数目就能减少到原来的1/4。
但如果是这样的话就又产生了一个问题,考虑到一个人可以同时在两个以上的牌桌上同时游戏,socket方面又有了问题,如果是对每个游戏者创建一个socket,那么就需要一个总的处理通信状态的线程来监视(特别是收)者的动作状态,并通知相应桌的线程,这样的话是不是会造成这个总线程的负担会太重以至于影响游戏速度呢? 
还有一个方法是每当游戏者进入一个游戏桌就产生一个线程,这样游戏者在本卓的动作就可以通过本卓的线程来处理。但这样也会产生一个问题,那就是socket太多,如果一个人同时在3桌上进行游戏的话,那就需要有12000个线程(因为大厅需要一个客户连接的线程)。以上是我的一些想法,请大家给点意见。

解决方案 »

  1.   

    想做通用的,必要时候移植到unix下面去,所以没考虑完成端口
      

  2.   

    另外寻<<unix网络编程电子书>>,最好是html 或者.chm 格式的,实在不行.pdf 也行。
    成功后另开100分相赠。
      

  3.   

    up,寻<<unix网络编程>>电子书,最好是html 或者.chm 格式的,实在不行.pdf 也行。
    成功后另开100分相赠。
      

  4.   

    就用select模式吧,UNIX上也可以用的。
      

  5.   

    最好在UNIX下实现。
    支持用select
    <Unix网络编程>有40多M ,PDF文件的,随便搜一下都可以找到
      

  6.   

    select性能不是最好的!!! 如果是在WINDOWS建议用完成端口吧,不过这个比SELECT复杂多了!
      

  7.   

    我是这样来看待这个问题的,和大家讨论一下,具体我没做过:1。首先我认为整个游戏服务器有一个侦听端口A,它负责用户的接入鉴权以及其他非游戏指令处理,比如:找人、消息通知、换游戏桌、对话、用户状态信息等等。
    2。我认为可以简单的做成每一桌游戏就有一个端口侦听,游戏者要参加哪桌游戏,向端口A查询即可获得某桌游戏侦听端口B的相关信息,从而连接之,连接通过后向端口A发通知告诉自己已经上了某桌了。这样很容易做成分布式系统,为日后系统扩展留下接口。
    3。每一桌作为一个单独的服务器模型来考虑这样可以大大减低系统的复杂度,从某种意义上来说,你只要实现一桌牌,那么和实现100桌和1000桌没什么2样了。这样的模型可便于重用。而且实现难度低很多。时间很紧,要下班了,改日再详细讨论。