GameSrv讨论 之 一

ShiChao

[quote:8d58dadeb0="sjinny"]我服务器端的架构图画好了，但是没法输出成png格式，是用Xfig画的~
但是怎么不能把.fig的文件上传到论坛上来呢？郁闷~[/quote]

xfig是啥？我都没用过。

wq1977

在file菜单里选择export ,在接下来的对话框里更改language.

sjinny

[quote:b68da1b6d2="wq1977"]在file菜单里选择export ,在接下来的对话框里更改language.[/quote]
是的，我知道，但是fedora里的xfig好象有点问题，我再用RH8的试试
另外，这里我严重向大家推荐用Xfig画软件架构图，比那个Dia好多了~~~~~~

sjinny

唉，把文件弄到RH8里还是不能输出，在Fedora里试了输出以前RH8里画的图倒是正常的~ 只好弄个屏幕截图，可能字小了点，先让大家明白我的意思吧~

sjinny

大家看看我的图吧，我的想法其实是把一些工作分给了几个线程去做，一个用户就要用三个线程：
一个用来从网络读数据，一个用来向网络发送数据，没有数据可读/发的时候相应的线程就挂起，还有一个线程用来管理这个用户的所有操作；
另外每个游戏桌都占用一个线程，可以考虑用线程池。

ShiChao

plugin是什么？ server需要模块吗？

wsm

我的想法其实是把一些工作分给了几个线程去做，一个用户就要用三个线程：

我感觉这样多的线程应该没必要的 能不能解释一下为什么需要这么多呢？
以我的想法 基本上server这边对各个用户的控制计算量不会很大
假定是一个打牌的游戏 基本上只是一些终盘的结果处理 出牌和比大小可以放在客户端作的就不需要发到服务器端校验了 这样 接受信息-〉处理-〉发回 即使在一个线程中作 用户也不会感到很慢

另外：用dia画嘛 方便 也没有什么能不能输出的问题

wq1977

多线程同时操作同一个socket不知道会不会有问题。

读和写都采用阻塞的方式，那么读的时候还可以写吗？

是不是一定要采用轮询的方式，还是要多建几个socket，每个客户端用两个socket，一个用来收，一个用来发。

不知道在apache中是怎么做的，源代码好深奥的说。

有一本书叫apache server 源代码分析，可惜还没有搞到。

sjinny

晕，大家还没完全理解我的图~
我解释一下：
服务器端为每个客户端创建一个TCP连接，所以一个客户端对应了一个socket（假如对socket的读写不会有矛盾的话，否则只好一个客户端对应两个socket了）。
关于Plug in：
因为服务器端要同时提供多种游戏服务，所以我想把每种游戏作为服务器端的一个模块来处理，所以一般情况下，一个Plug in就是一种游戏，具体就是一个.so文件（动态连接库）。
关于多线程：
我考虑到各个模块对信息处理的速度是不完全一样的，所以如果不用多线程，可能会有性能瓶颈，比如：
假如Manage模块和所有User、Socket共用一个线程，那么可能会出现以下情况：
Manage要在数据库里查询一个User的数据，因为User很多，所以查询花了不少时间，而此时对所有User数据的处理就都停顿了，于是任何一个User发给服务器的数据到达后，Manage的线程因为在等待数据库查询结果的返回而没有去处理那些已经到达的网络数据，此时socket虽然可读出数据，但是却没有线程去处理它，而此时所有的游戏都在进行中（一个游戏一个线程或进程是肯定的），假如有的游戏对玩家的操作有时间限制的话，一旦数据库查询时间比游戏时间限制还长，那么所有玩家都会因为这次数据库操作而在游戏中超时。
另外，服务器端其实还是有不少计算量的，因为服务器不仅在游戏前要起牵线搭桥的作用，而且在游戏过程中还要起到“裁判”的作用，要保证游戏的公平公正，所以打牌时，必须由服务器来判断各玩家出牌的大小和游戏结果；不放在客户端是因为游戏的客户端是开源的，那么任何一个稍懂编程的人就可以更改客户端代码而实现作弊。

默难

个人感觉没有必要采用那么多的线程，因为毕竟每个进程只能拥有1024个线程。
至于Apache，据说几个用户拥有一个进程——小道消息，不知道是真是假。个人感觉每个用户一个socket足以

sjinny

socket是双工的吗？假如我在一个线程里阻塞地读取socket，另一个线程里阻塞地写同一个socket，那么会有问题吗？
另外，说说是采用多进程还是多线程的问题，各个游戏桌间当然没什么通信，但是游戏桌和主程序间是要有通信的，否则哪个游戏结束了，游戏结果就没法汇总记录了，而且哪个游戏桌发生了死锁之类的主程序也无从知晓，也就没法处理了，而且这时服务器的管理员也无法知道是否有游戏进程死锁了，如果是死循环，那么就会一直耗费服务器资源却没人知道~

默难

没记错的话……socket好像是全双工的（具体我在查查，这个以后再议）
正是有由于各个桌面之间没有通讯而桌面与主进程（注意，我的意见是采用多进程并配合多线程）之间有数据的传输，但是它们之间传输的数据量不会相当大，因此我的意见是：在各个桌面与主进程之间保存一片共享的内存，这样速度是可以忍受并且能保持各个桌面之间的相对独立。
每个用户拥有一个线程，这样可以让用户之间相对的比较独立，但又可以进行快速的通讯。

wsm

1。所有人都用一个线程当然不合理。但我想游戏中组织是合理的，还是比方打牌一桌人用一个服务线程很合理，因为其中一个人没有作完前后面谁也不该动。即使某个人超时了也是合理的。
2。数据库的操作只出现登陆计分的情况下 也就是用户连服务器和游戏（重）新开局的时候，这个时候所有的人都在等待，而并没有作操作，即使时间长也是合理的。而玩家操作如果超时的时候可以保证没有数据库操作在同时发生。
3。从协议角度来看socket是双工，但是代码不是双工，代码某个部分在等待写入消息的时候就没办法等待受到消息了。但这个问题也应该不存在，我们只是对登陆这样的处理多人消息的时候需要考虑，在游戏的处理中由于每个人的每个操作都是线性的，不会有一个人还需要多个端口的问题。
4。plugin的想法很先进 但是我认为静态的可靠性比较好做起来难度也小 （plugin要求主干能够提供一个很灵活可扩展又要很牢固可靠的接口 这是很难的）游戏服务直接做成实际的程序，启动脚本中启动他们或者在登陆服务程序中（我们的名称也该要确定一下了）读取配置文件启动
5。实现使用进程还是线程，理想的情况我认为还是做成为可配置的为好，根据实际情况灵活使用。

wsm

另一个讨论的是线程和主线程的通讯问题
一个死锁，我想该算是bug吧？真的出现了那肯定是这个游戏本身代码的问题了。
还是以打牌为例，线程和主线程的通讯十分简单，他们之间只需要登记/撤销桌号
一个锁和一个公共结构即可

wq1977

可以同时读，但是不能同时写。这样才能提高效率。
应该考虑随时有可能收到客户端的消息，即使游戏已经开始了，也许某人想逃跑，也许客户端想实现聊天的功能。

当收到客户端的消息的时候，至少要知道应该往哪个socket里面写。