GameSrv讨论 之 一

sjinny

几个问题：
1。Linux下一个进程可以创建多少个线程和socket连接？2.6的内核呢？如果一个进程下有上千个线程，是否会有什么问题？
2。一个TCP连接是否要和一个端口一一对应？如果一个服务器要和上千个客户端建立TCP连接的话，岂不是要占用上千个端口？？
3。2.6内核里是否有什么我们应该注意的新特性？我只记得似乎有个内存池的新功能~
4。一般一个具体的游戏都会有自己的网络协议，那么服务器端主程序应该针对这一点做哪些设计呢？
5。目前我们需要哪些正式的文档？
6。开发语言、开发工具各是哪些？协作机制是什么？CVS还是手工组装代码还是其他？在哪个协作开发站点申请项目？
7。用socket建立的网络连接是不是只能用c风格来操作流啊？C++的流和socket连接能结合起来吗？

还有什么要明确的也请大家来补充~

ShiChao

有没有考虑跨平台的？
socket接收数据，用线程还是用进程？

ps. Mozilla实在不好用，受不了了

sjinny

我的初步想法是：
客户端和服务器端间建立TCP连接，在服务器端：
一个线程负责把一个消息队列里的数据写入这个连接，并处理和发送有关的错误；
一个线程负责用阻塞的方法从连接里读取数据，每次读取了数据后这个线程会把数据发送到处理这个数据的线程的消息队列里，这个线程也要处理和网络读取有关的错误；
一个具体的游戏（一个游戏桌）使用一个线程；
创建一个新游戏其实就是创建一个新的游戏线程~
等我明天考完试用软件画出来可能更好理解些~

sjinny

关于跨平台：
服务器端跨平台的必要性有多少？
客户端则没有必要，只要把协议设计好，哪怕另外开发for Windows的客户端也没关系，不能因为要跨平台而留下设计缺陷~

ShiChao

[quote:3e6eb09464="sjinny"]我的初步想法是：
客户端和服务器端间建立TCP连接，在服务器端：
一个线程负责把一个消息队列里的数据写入这个连接，并处理和发送有关的错误；
一个线程负责用阻塞的方法从连接里读取数据，每次读取了数据后这个线程会把数据发送到处理这个数据的线程的消息队列里，这个线程也要处理和网络读取有关的错误；
一个具体的游戏（一个游戏桌）使用一个线程；
创建一个新游戏其实就是创建一个新的游戏线程~
等我明天考完试用软件画出来可能更好理解些~[/quote]

辛苦啦

"这个线程也要处理和网络读取有关的错误" 什么意思？

这样的网络程序跨平台不是很难，像pthread库，win32都有对应的API。socket函数也是相同的。

sjinny

"这个线程也要处理和网络读取有关的错误"：
解释：
当从网络流里读取数据时相关的读取操作发生了错误，这个线程要自己把这个错误处理好，处理不了就要报告给主进程~

ShiChao

接收数据的线程通过队列传给这个线程, 这个线程怎么会涉及到"读取数据时相关的读取操作发生了错误"?

sjinny

晕，再读一遍才发现我那句话说得不好，我的意思是：
一个线程负责用阻塞的方法从连接里读取数据，每次读取了数据后这个线程会把数据发送到处理这个数据的线程的消息队列里；这个（负责从网络流读取数据的）线程也要处理和网络读取有关的错误。

默难

关于第一个问题，我只知道一个进程可以创建1024个线程（记不清了，反正是4位数——十进制的四位数……）至于多少个socket连接……记不清了，我可以查查
第二个问题：不是，可以设置SO_REUSEADDR
其他的问题……我看看，再慢慢回答～
很遗憾没有时间来参加这个项目，不过需要帮忙的话我会来的，比如写个函数什么的我绝对不会含糊~~

默难

如果这样的话，整个软件只是利用一个进程？
我的建议：
每个桌面一个进程
每N个用户一个线程
每个桌面的进程都是一个进程的子进程。这个进程暂时叫做主进程。
主进程的任务：
fork子进程（桌面）
为每一个桌面维护一块共享的内存区域
接受消息，并判断接受的消息是否合法，将合法的消息放到相应的桌面的共享内存里面。

sjinny

我的映象中好像进程的切换比线程要慢~
而且进程间通信也比较麻烦，特别是要传送大块数据的话，不能像一个进程里那样传个指针完事~

sjinny

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

默难

确实线程的切换比进程快，但是：
进程可以相对独立的运行，这样就可以保护很多数据，因为这个系统的每个游戏桌面是相对独立的，几乎（甚至是根本）不与其他桌面进行通信，因此我觉得还是采用进程比较好，至于接收数据，我刚才想了想，还是不要让主进程负责，由每个桌面的进程负责吧。

wq1977

每个桌面一个进程的想法我觉得有创意。
记得在不知道什么地方看到，linux的进程数目收到某个数据结构的限制，默认最大只支持500多个进程。如果是每个用户一个进程可能确实不太充分。

wsm

建议在邮件列表上讨论吧 不然老是看不见
1。我们完全不需要这么多的线程 举个例子；打牌 每个人大概一秒钟出一张是可以忍受的而且服务计算量不大，那么我们可以考虑负载的情况一个游戏的服务线程维护2桌数据
假如是下围棋，我们认为10秒钟下一步也已经比较合理了，那么这里的一个游戏服务线程控制20桌也够了
假如我们测试中认为还可以加大这个负载，那么30桌也可以
这些都是游戏自己可控制的
第二个问题也是一样 我们对负载高的游戏需要一个人一个端口，相应我们支持的桌数也就少了，对于负载低的游戏，可以全都用一个端口，用id来区分
即使退一步来说我们真的需要几千的线程，几千端口，那也不是什么很奇怪的问题，几千个人的话，无论怎么设计负载总是在哪儿的，真正的网页服务器上支持上万用户也不奇怪，只是机器的问题罢了
当然我们要把越多的东西做成可配置的越好
关于代码的实现，我想在服务器段使用c是比较确定了的，大家都懂，而且系统支持好，用c++就要用什么别的库，容易搞混。
客户端就可选项比较多了，不过现在还不关注这个