关于"登陆服务器"的架构设计
关中刀客
最近在设计这个"登陆服务器"。设计了几个方案都感觉缺陷很大。这个"登陆服务器"主要的职责是接受客户端的登陆请教（帐号+密码）。然后发
给"数据库服务器"验证，如果数据库里面有的话，"数据库服务器"发包（包括这个用户的具体信息）给"登陆服务器"，然后"登陆服务器"把这个信息发给
一个"大厅服务器"，然后把这个"大厅服务器"的port 和IP发回给客户端，客户端在区连接"大厅服务器".............
为了同时可容纳很多的人"登陆"，我在"登陆服务器"中使用IOCP连接和接受客户端请求，单独开一个线程接受"数据库服务器"的数据，同
时又有几个socket连接着"大厅服务器"。
现在的问题就是：在这个"完成端口"的线程池处理函数中，只需要recv一次客户端的信息。而我每次有客户端连接的时候。都要new全局的"句
柄结构"和"数据结构体"，把它和IOCP连接起来。等受到了消息后，就通过和"数据库服务器连接的socket"法给"服务器服务器"。这样子，我感
觉没有合理的运用iocp,并贴会new很多的"结构体"，然后只能在返回给客户端消息后delete .这样子程序很快就没空间可分配了，尽管我只用
了"对象池"
请大家根据自己的经验指点一下，谢谢.
sunway
这个问题网络上大把的例子，建议你先去CodeProject上找代码看看。
qiaojie
sunway
1.因为登陆服务器是并发连接多.
2.单连接通讯数据量小。
3.用户不介意等个几秒。
我做过的loginserver并发连接都比较高，经常5k并发连接以上。
我一般的做法是前面2*CPU个数的iocp线程，后面8～12个db线程。基本上够用了。
On May 24, 4:37 pm, qiaojie <qiao...@gmail.com> wrote:
> 这种应用没必要用什么IOCP，徒增编程复杂度。你的问题是没有做拥塞控制，接受连接的吞吐量超过了后端数据库IO的吞吐量，导致一段时间以后累积了很多后端来 不及处理的连接，你又不控制拥塞导致内存耗尽。其实用非阻塞的select轮询就足够了，网络层自动的帮你做了拥塞控制从而简化了编程。
>
> 在07-5-24，关中刀客 <guanzhongda...@gmail.com> 写道：
>
>
>
>
>
> > 大家好：
> > 最近在设计这个"登陆服务器"。设计了几个方案都感觉缺陷很大。这个"登陆服务器"主要的职责是接受客户端的登陆请教（帐号+密码）。然后发
> > 给"数据库服务器"验证，如果数据库里面有的话，"数据库服务器"发包（包括这个用户的具体信息）给"登陆服务器"，然后"登陆服务器"把这个信息发给
> > 一个"大厅服务器"，然后把这个"大厅服务器"的port 和IP发回给客户端，客户端在区连接"大厅服务器".............
>
> > 为了同时可容纳很多的人"登陆"，我在"登陆服务器"中使用IOCP连接和接受客户端请求，单独开一个线程接受"数据库服务器"的数据，同
> > 时又有几个socket连接着"大厅服务器"。
> > 现在的问题就是：在这个"完成端口"的线程池处理函数中，只需要recv一次客户端的信息。而我每次有客户端连接的时候。都要new全局的"句
> > 柄结构"和"数据结构体"，把它和IOCP连接起来。等受到了消息后，就通过和"数据库服务器连接的socket"法给"服务器服务器"。这样子，我感
> > 觉没有合理的运用iocp,并贴会new很多的"结构体"，然后只能在返回给客户端消息后delete .这样子程序很快就没空间可分配了，尽管我只用
> > 了"对象池"
> > 请大家根据自己的经验指点一下，谢谢.- Hide quoted text -
>
> - Show quoted text -
关中刀客
select好像在windows平台上很少用，因为效率很低，浪费cpu
> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
sunway
分配用户倒合适的线程。IOCP把这些都做了。
2。正常情况下在并发10000连接请求是在热点时间，比如晚上7点等，过了这个时间段人数就会少很多，10000个并发连接，并不是每秒都有
10000个连接请求，如果服务器做了最大并发连接限制的话，10000个连接请求在每秒3000处理能力的情况下4秒能处理完，login用户多等个
几秒也没有关系，如果是select模式剩下的7000连接用户需要重新连接了，付出的开销更大。
On 5月24日, 下午8时13分, qiaojie <qiao...@gmail.com> wrote:
> 并发连接数意义不大，主要看你的每秒最大能处理的登陆请求数，如果你的后端最大每秒只能处理3000个请求，而你接受10000多个连接在用户层就没什么意义， 还不如缓冲在网络层，网络层缓冲满了系统就开始拒绝连接，这可以防止风暴连接的时候把服务器压垮。
> 至于登陆服务器用select毫无问题，因为都是短时的连接，一般你select的时候大多数情况数据已经可读，不存在大量idle
> connection的情况，用iocp不会有什么性能上的优势。
>
> 在07-5-24，sunway <sunhui...@gmail.com> 写道：
>
>
>
>
>
> > 个人感觉登陆服务器有必要用完成端口或者EPOLL，
> > 1.因为登陆服务器是并发连接多.
> > 2.单连接通讯数据量小。
> > 3.用户不介意等个几秒。
> > 我做过的loginserver并发连接都比较高，经常5k并发连接以上。
> > 我一般的做法是前面2*CPU个数的iocp线程，后面8～12个db线程。基本上够用了。
>
> > On May 24, 4:37 pm, qiaojie <qiao...@gmail.com> wrote:
>
> > 这种应用没必要用什么IOCP，徒增编程复杂度。你的问题是没有做拥塞控制，接受连接的吞吐量超过了后端数据库IO的吞吐量，导致一段时间以后累积了很多后端来
> > 不及处理的连接，你又不控制拥塞导致内存耗尽。其实用非阻塞的select轮询就足够了，网络层自动的帮你做了拥塞控制从而简化了编程。
>
> > > 在07-5-24，关中刀客 <guanzhongda...@gmail.com> 写道：
>
> > > > 大家好：
> > > > 最近在设计这个"登陆服务器"。设计了几个方案都感觉缺陷很大。这个"登陆服务器"主要的职责是接受客户端的登陆请教（帐号+密码）。然后发
>
> > 给"数据库服务器"验证，如果数据库里面有的话，"数据库服务器"发包（包括这个用户的具体信息）给"登陆服务器"，然后"登陆服务器"把这个信息发给
> > > > 一个"大厅服务器"，然后把这个"大厅服务器"的port 和IP发回给客户端，客户端在区连接"大厅服务器".............
>
> > > > 为了同时可容纳很多的人"登陆"，我在"登陆服务器"中使用IOCP连接和接受客户端请求，单独开一个线程接受"数据库服务器"的数据，同
> > > > 时又有几个socket连接着"大厅服务器"。
> > > > 现在的问题就是：在这个"完成端口"的线程池处理函数中，只需要recv一次客户端的信息。而我每次有客户端连接的时候。都要new全局的"句
>
> > 柄结构"和"数据结构体"，把它和IOCP连接起来。等受到了消息后，就通过和"数据库服务器连接的socket"法给"服务器服务器"。这样子，我感
> > > > 觉没有合理的运用iocp,并贴会new很多的"结构体"，然后只能在返回给客户端消息后delete
> > .这样子程序很快就没空间可分配了，尽管我只用
> > > > 了"对象池"
> > > > 请大家根据自己的经验指点一下，谢谢.- Hide quoted text -
>
qiaojie
sunway
2，ddos攻击应用软件来抵御根本就没有可能。
3，你也承认loginserver的用户对于实时性没有需求，那么他们任一个用户
都是idle的， 只要服务器能在1～5内给回应就OK了。按你的说法应该更适合
用iocp/epoll。
4，你的处理逻辑里面做了大量的轮询遍历操作，比较费CPU。
On 5月24日, 下午9时07分, qiaojie <qiao...@gmail.com> wrote:
> 开那么多线程干吗？我从来都是单线程non-blocking
> select，轮询一遍5000个socket是用不了多少时间的(大约几个ms),，登陆没必要提供很快的响应时间，你可以间隔上百ms才轮询一次，在收到一 组用户数据后再批量传送给数据库验证，这里可以用线程池来提高IO使用效率。
> 至于连接则由网络层负责缓冲，你可以把缓冲区设置的大一些改善连接吞吐量，比方说我每隔50ms查询一遍侦听端口，连接缓冲设置为100，这样理论上说我每秒最 多可以接受2000个新连接，缓冲区满了网络层就不再响应TCP握手消息了，这样最多让用户收到个连接超时的错误，对服务器来说不会造成很大的开销，反之你不加 控制一股脑全连接进来又来不及处理，时间一长应用层累积了大量未处理连接可能导致资源耗尽，如果遇到DDOS攻击那么情况就更严重了。
>
> 在07-5-24，sunway <sunhui...@gmail.com> 写道：
> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
关中刀客
采用IOCP，然后设置一个IOCPDispatchThread, 每次客户连接的句柄结构和发送的overlapped数据结构都存放到一
个map表里面，主键用这个这个连接socket,然后把它的包结尾加上这个socket传递给"数据库服务器"，数据库反正完后返回信息（当然结尾有
这个socket），然后"登陆服务器"根据这个socket从map表里面找到这个"句柄结构体和overlapped数据结构体"，投递
WSASend给客户端信息。然后在iocp的线程里面受到send OK 消息时回收这个"句柄结构体和overlapped数据结构体"
大家感觉怎么样？
liam
因为可能数据库返回包中的socket已经不代表原来的客户端了?不知道前辈们怎么看的.
关中刀客
这个socket在没有等到"数据库服务器段返回+返回给客户端"这两件事完成是不会关闭的
关键的问题就是：
怕一个很多连接和登陆，那么前面的分配的全局"句柄结构体"和"overlapped数据结构体"还没回收完,就有很多的连接登陆，这样子
我怕再跟他们分配这些结构体会失败
Ghost Cheng
如果是客户端主动关闭呢？考虑过没有？
当客户端主动断开了连接后，这个socket值，也许会在accept时分配给另一个客户端。
--
Sincerely,
Ghost Cheng
Email : ghost...@gmail.com
Web : http://www.GhostSoft.net
关中刀客
，客户端受到后就断开连接，然后去连接"大厅服务器"。但是如果在这个中间客户端断开了连接就.......，因为在iocp的线程里面得到登陆信息后
就没有再recv了，客户端断开了也就没办法通知了，好像.........
On 5月24日, 下午10时23分, "Ghost Cheng" <ghost.ch...@gmail.com> wrote:
> "这个socket在没有等到"数据库服务器段返回+返回给客户端"这两件事完成是不会关闭的"
>
> 如果是客户端主动关闭呢？考虑过没有？
> 当客户端主动断开了连接后，这个socket值，也许会在accept时分配给另一个客户端。
>
> Email : ghost.ch...@gmail.com
> Web :http://www.GhostSoft.net- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Ghost Cheng
通常我会将所有在线的用户，按ID、名字、或者临时ID，存进一个hashmap中，下线后就删掉，收到其他服务器传来的消息是，先找在这个map中查询一下，user是否在线，再做处理。
On 5/24/07, 关中刀客 <guanzho...@gmail.com> wrote:
--
Sincerely,
Ghost Cheng
Email : ghost...@gmail.com
Web : http://www.GhostSoft.net
Ghost Cheng
IOCP/EPOLL，可以最大程度的的处理大量并发连接，这些连接分配到不同的线程里去处理，没有任何需要线程间同步的地方，这种情况下，多线程+IOCP/EPOLL
显然比 单线程non-blocking 更加符合应用需求，以及能够更加发挥系统的最佳性能。
单线程只该应用在复杂逻辑的服务器应用上，比如游戏的场景服务器，那种情况下，每个客户端连接之间，都存在很多需要共享的数据，多线程处理的话，需要大量的线程同步操作。
关中刀客
ghost 真高手，对于你说的那个，我认为主要应用在"已经正常的登陆，连接大厅服务器，并且进入了一个"战区了"，这个时候我们在内存中会村一部分
的用户资料，用什么内存影射==都可以，然后用心条包来判断用户是否还"活"着。
但是在"登陆服务器的时候"，在IOCP的处理线程中，我们接受到了客户端的数据后，虽然客户端只会发送一次信息，但是我们在recv消息受到登陆信息
后在此投递WSARecv，用于监听客户端是否断开，然后用全局的一系列bool值来判断每次socket是否已经改变
当然这个也是ghost的思想，我只是在重复了一下，呵呵，详细的细节我要做好了才能在说了
谢谢大家阿，3KS
On 5月24日, 下午10时55分, "Ghost Cheng" <ghost.ch...@gmail.com> wrote:
> 所以，服务器之间的数据交互，必须都带上给每个客户端分配的唯一标志，当收到另一个服务器传来的针对某一个客户端的数据时，第一件要做的事情，就是查询这个客户 端是否还在线。
> 通常我会将所有在线的用户，按ID、名字、或者临时ID，存进一个hashmap中，下线后就删掉，收到其他服务器传来的消息是，先找在这个map中查询一下， user是否在线，再做处理。
>
> > > Web :http://www.GhostSoft.net-隐藏被引用文字 -
Yun Fan
关中刀客
注册和登陆不是一个服务器，在"数据库服务器"那边因该把"合适"的信息先放到
内存中，然后固定的时间把这些写入数据库，这样子可以实现缓冲的功能
On 5月25日, 上午10时14分, "Yun Fan" <fanyun2...@gmail.com> wrote:
> 是否可以把用户的帐号和密码都cache 起来认证呢？ 避免数据库压力？
qiaojie
Ghost Cheng
LoginServer,通常是直接连接到数据库上操作，对数据库访问时，可以肯定，有大量的idle connection 在等待数据库的返回结果。
第二，更不赞成这句话："至于在性能方面，iocp/epoll不会有很大的优势，
用iocp/epoll的前提是：1、连接数大，2、有大量idle connection。"
如果你这么认为，那我真的不知道该说什么了。。。。
在网络游戏的服务器设计上，可以肯定的说IOCP/EPOLL的性能，绝对不是select模型可比的。游戏的实时性要求不高么？游戏中的玩家连接，是不可能存在大量的idle
connection 的。那么按照你的想法，使用select模型的服务器，能带的了多少玩家同时在线?这个问题似乎已经有N多的实例数据了。
DEMON
qiaojie
Ghost Cheng
你所说的轮询耗时6～10MS，加上了recv数据，memcpy，压入数据队列的时间么？
"每隔100ms进行一次轮询" 对于实时性要求比较高的MMO来说，这是不可忍受的。你每轮询10次，就给服务器和用户之间的通讯浪费了1秒钟的时间。
另外你测试用的1000个客户端，使用了几台物理客户端机器？如果数量不多的话，那么根本就没有正真模拟出1000个客户端的并发连接。那些机器根本不可能模拟出几百个连接同时发送数据。几乎可以肯定，你的这1000个连接发送到服务器的数据，大多是排着队进来的。
Ghost Cheng
拿征途来说，单个客户端每秒中的数据下载量超过20K。
30%的CPU负载，只处理了1000个想像中的"并发"客户端的移动消息。
如果再加上其他，场景数据，攻击数据，角色数据等等，并且还有N多的数据，需要从服务器上发送到各个客户端。你觉得呢？
qiaojie
Yun Fan
--
Regards
FanYun
qiaojie
Yun Fan
Regards
FanYun
qiaojie
Ghost Cheng
但是对于超过1000，2000，甚至更多的客户端来说呢？
另外，征途的流量确实比其他的游戏要大一些。
qiaojie
Ghost Cheng
服务器上每1MS都是很重要的，不应该把时间浪费在这里。
lijie
我是说，你等了100MS之后再处理1个客户端的数据，和等了100MS后，再处理1000个客户端的数据是不一样的。
服务器上每1MS都是很重要的，不应该把时间浪费在这里。
Ghost Cheng
select这种模型，在处理成千上万的并发连接时，不能做到最快速的响应。
就算你1000个客户端轮询一遍只需要6～10MS，但是IOCP/EPOLL，对于客户端响应是即时的，我们不需要刻意去做什么100MS的等待，不需要把CPU时间花在毫无意义的轮询上，当有数据处理时，就处理，当没有数据处理时，线程就可以idle。
你在处理1000个连接的时候，也许你觉得select可以满足你的要求，但是当你的业务逻辑开始增长，并发连接数开始增加的时候，负载也会成几何级的增长。那你的用户数量更多的时候，你会发现select是多么让人郁闷的模型。几十年前的技术是用来满足当时的情况的，现在时代变了，需求也变了。
PS：况且，你的测试的环境，并不是真正的1000个并发连接，每台机器200个线程发送数据，已经让第一个线程和最后一个线程工作的时间间隔很大了。个人认为你去做那100MS的等待，无非就是将这100MS内收到的数据集中到一批处理罢了。
qiaojie
我是说，你等了100MS之后再处理1个客户端的数据，和等了100MS后，再处理1000个客户端的数据是不一样的。
qiaojie
总之，在针对大量并发连接的时候，IOCP/EPOLL模型的效率，根本不是select能够比拟的。IOCP/EPOLL，正是为了解决select各项缺点，才被发明出来的。
Ghost Cheng
"有数据就处理这种模式恰恰就是低效的根源，要提高效率就应该batch处理"
个人观点，你这是图形渲染的方面搞的太多，将显卡和网络联想到一起了，网络编程和对显卡的渲染管线编程并不一样。socket编程，你必须考虑很多的非人为的，不可控的突发事件。batch处理recv数据，想法也许是好的，但是如果当你的主循环idle时，socket的buffer满了怎么办？
（PS：不要认为我只是个写写服务器代码的家伙，对3D方面一无所知，在这里大放厥词，事实上我写过不止一个图形渲染引擎。）
"另外你要及时响应就要使用多线程，这增加了很多线程切换开销"
难道你看到的使用IOCP/EPOLL的代码，都是开了几十上百个GET线程？通常我们使用IOCP/EPOLL时，所开的线程数量都是根据CPU数量做了优化，得到的结果。可以保证最大程度的合理利用CPU资源。而在这里使用单线程，恰恰浪费了很多CPU周期，这也是多线程处理的概念被发明的原因。
"用什么方案还是要根据具体的应用来分析"
这句话我倒是赞同的，依据以往的经验和案例，并发连接数大于1000的就已经不太适合select模型了。当然，也许你的项目，通讯量并不大，致使你的测试结果，看起来能够让你接受。
"把采用什么IO模式当成判断系统性能的标准"， 貌似这种对我的回帖断章取义的做法更加的幼稚。
qiaojie
Ghost Cheng
"你在线程等待事件->处理->再等待，这个从等待到唤醒的过程难道没有系统开销吗"
如果你认为这个是在浪费CPU资源，那么多线程这个概念，不要也罢。单线程"足以高效"的处理一切了。
"至于单线程恰恰浪费了很多CPU周期，我想听听你理由。"
最简单的例子：按你的说法，你的主循环轮询完了之后的，如果还不到100MS，那么就sleep。
那么这个时间就是被浪费的CPU周期。这时本可以利用CPU的空闲，做其他的操作，或将CPU交给另一个线程工作。
人们发明了多线程编程，就是为了更好的利用，单线程处理的时候CPU被闲置的情况。
好了，我认为这个问题继续争论下去，已经没什么意义了。注意我用的是"争论"而不是"讨论"，这已经不是讨论了，而是毫无意义的争论。
既然你这么坚持的认为select比IOCP/EPOLL更高效，看起来，我除了表示一些反对意见以外，已经没有必要再争论什么了。各自按各自的想法去做吧。
qiaojie
Ghost Cheng
这个我赞同，现在也确实是这么做的，我会将消息缓存一下，满了64K才发送，当然有时间限制，超时后，直接发送。
但是在响应socket的数据时，仍然是即时响应。
Yun Fan
sunway
1,TCP有滑动窗口,接受方的BUFFER满了会通知发送方.
1,TCP协议内部已经缓冲算法,对于小包会缓冲一段时间再发送,所以很多实时性高的应用会用UDP或者关掉TCP的缓冲算法,因此程序根本不用做这样
的优化.相反,很多游戏服务器关掉缓冲算法的来提高实时性,对于游戏网关这样程序不用延迟发送,有数据直接发就OK了
On 5月26日, 下午1时50分, qiaojie <qiao...@gmail.com> wrote:
> 呵呵，看来你是完全听不进我的观点了，不过我到是建议你修改一下你那个征途的网关服务器，不立刻发送消息到后端，先缓存一段时间再一起发送，同时向用户发送消息 时也不要马上发送，先缓存在自己的buffer里，一段时间后再一起发送，看看这样有没有性能上的提升。...
>
> 阅读更多
>
> 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
>
>
>
>
>
> > 多线程处理游戏逻辑当然是不可能的。不过最普遍的做法是，游戏逻辑由单独的服务器来完成，并不需要处理成千上万的socket连接，而真正与用户进行网络数据交 换的网关服务器，并不需要处理游戏逻辑。N个GET线程的recv完了之后，并不一定需要将数据压到一个队列中，可以直接send到逻辑服务器。
>
> > "你在线程等待事件->处理->再等待，这个从等待到唤醒的过程难道没有系统开销吗"
> > 如果你认为这个是在浪费CPU资源，那么多线程这个概念，不要也罢。单线程"足以高效"的处理一切了。
>
> > "至于单线程恰恰浪费了很多CPU周期，我想听听你理由。"
> > 最简单的例子：按你的说法，你的主循环轮询完了之后的，如果还不到100MS，那么就sleep。
> > 那么这个时间就是被浪费的CPU周期。这时本可以利用CPU的空闲，做其他的操作，或将CPU交给另一个线程工作。
> > 人们发明了多线程编程，就是为了更好的利用，单线程处理的时候CPU被闲置的情况。
>
> > 好了，我认为这个问题继续争论下去，已经没什么意义了。注意我用的是"争论"而不是"讨论"，这已经不是讨论了，而是毫无意义的争论。
> > 既然你这么坚持的认为select比IOCP/EPOLL更高效，看起来，我除了表示一些反对意见以外，已经没有必要再争论什么了。各自按各自的想法去做吧。
>
> > On 5/26/07, qiaojie <qiao...@gmail.com> wrote:
>
> > hoho，看来你也是把我的话断章取义来理解，这样下去恐怕是要发展成意识形态之争了，好吧，我先收回我最后说的那句话。你也先不要那么激动，大家摆事实讲道理 。
>
> > >个人观点，你这是图形渲染的方面搞的太多，将显卡和网络联想到一起了，网络编程和对显卡的渲染管线编程并不一样。socket编程，你必须考虑很多的非人为的 ，不可控的突发事件。batch处理recv数据，想法也许是好的，但是如果当你的主循环idle时，socket的buffer满了怎么办？
>
> > > 首先正常情况下recv buffer不可能满，就算用户故意发送巨量请求或者因为网络阻塞把recv
> > > buffer撑满了，那也只是在客户端的send buffer里缓存，如果send
>
> > buffer也满了则客户端阻塞，你觉得这有什么问题？反倒是很好的帮你做了拥塞控制，同时也可以防止黑客攻击把服务器压垮了。事实上我通常会刻意把recv
> > > buffer设置的小一些。
>
> > >难道你看到的使用IOCP/EPOLL的代码，都是开了几十上百个GET线程？通常我们使用IOCP/EPOLL时，所开的线程数量都是根据CPU数量做了优 化，得到的结果。可以保证最大程度的合理利用CPU资源。而在这里使用单线程，恰恰浪费了很多CPU周期，这也是多线程处理的概念被发明的原因。
>
> > 你在线程等待事件->处理->再等待，这个从等待到唤醒的过程难道没有系统开销吗？另外你也不可能多线程处理游戏逻辑吧？还得另外用一个队列来排队用户请求，这 不是开销吗？至于单线程恰恰浪费了很多CPU周期，我想听听你理由。
>
> > >这句话我倒是赞同的，依据以往的经验和案例，并发连接数大于1000的就已经不太适合select模型了。当然，也许你的项目，通讯量并不大，致使你的测试结 果，看起来能够让你接受。
>
> > > 在你的论述中，我看到的更多的是你根据经验的判断，如果你能拿出更多的分析和量化数据的话我想会更有说服力。
>
> > > 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
> > > > hoho～～看来微软和开源社区的一帮白痴，花了那么多精力开发出了两个更加低效的IO模型。。。嗯，佩服。
>
> > > > "有数据就处理这种模式恰恰就是低效的根源，要提高效率就应该batch处理"
>
> > 个人观点，你这是图形渲染的方面搞的太多，将显卡和网络联想到一起了，网络编程和对显卡的渲染管线编程并不一样。socket编程，你必须考虑很多的非人为的， 不可控的突发事件。batch处理recv数据，想法也许是好的，但是如果当你的主循环idle时，socket的buffer满了怎么办？
>
> > > （PS：不要认为我只是个写写服务器代码的家伙，对3D方面一无所知，在这里大放厥词，事实上我写过不止一个图形渲染引擎。）
>
> > > > "另外你要及时响应就要使用多线程，这增加了很多线程切换开销"
>
> > 难道你看到的使用IOCP/EPOLL的代码，都是开了几十上百个GET线程？通常我们使用IOCP/EPOLL时，所开的线程数量都是根据CPU数量做了优化 ，得到的结果。可以保证最大程度的合理利用CPU资源。而在这里使用单线程，恰恰浪费了很多CPU周期，这也是多线程处理的概念被发明的原因。
>
> > > > "用什么方案还是要根据具体的应用来分析"
>
> > 这句话我倒是赞同的，依据以往的经验和案例，并发连接数大于1000的就已经不太适合select模型了。当然，也许你的项目，通讯量并不大，致使你的测试结果 ，看起来能够让你接受。
>
> > > > "把采用什么IO模式当成判断系统性能的标准"， 貌似这种对我的回帖断章取义的做法更加的幼稚。
>
> > > > On 5/26/07, qiaojie <qiao...@gmail.com> wrote:
>
> > 嘿嘿，有数据就处理这种模式恰恰就是低效的根源，要提高效率就应该batch处理。响应时间跟性能是矛盾的，举个例子吧，假设用户平均每秒钟发送20个请求，如 果你及时响应的话则需要20次recv调用，而如果服务器以10Hz的频率轮询，那么实际上服务器每秒不到10次recv调用，节省了一半的recv开销。另外 你要及时响应就要使用多线程，这增加了很多线程切换开销。所以这个例子里轮询的IO性能比及时响应至少提高一倍。
>
> > 当然了，我也承认select是存在着局限性，在上例中我也确实可以用epoll优化掉select轮询的开销，但是只能提高不到10％的整体性能，意义并不大 。用什么方案还是要根据具体的应用来分析，但是把iocp/epoll当成是万能药，把这做为提高性能的唯一方法，而不去分析具体应用的特性不去合理的分配系统 资源，这样做出来的系统反而更低效。把采用什么IO模式当成判断系统性能的标准，这种判断幼稚了点。
>
> > > > > 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
>
> > 总之，在针对大量并发连接的时候，IOCP/EPOLL模型的效率，根本不是select能够比拟的。IOCP/EPOLL，正是为了解决select各项缺点 ，才被发明出来的。
> > > > > > select这种模型，在处理成千上万的并发连接时，不能做到最快速的响应。
>
> > 就算你1000个客户端轮询一遍只需要6～10MS，但是IOCP/EPOLL，对于客户端响应是即时的，我们不需要刻意去做什么100MS的等待，不需要把C PU时间花在毫无意义的轮询上，当有数据处理时，就处理，当没有数据处理时，线程就可以idle。
>
> > 你在处理1000个连接的时候，也许你觉得select可以满足你的要求，但是当你的业务逻辑开始增长，并发连接数开始增加的时候，负载也会成几何级的增长。那 你的用户数量更多的时候，你会发现select是多么让人郁闷的模型。几十年前的技术是用来满足当时的情况的，现在时代变了，需求也变了。
>
> > PS：况且，你的测试的环境，并不是真正的1000个并发连接，每台机器200个线程发送数据，已经让第一个线程和最后一个线程工作的时间间隔很大了。个人认为 你去做那100MS的等待，无非就是将这100MS内收到的数据集中到一批处理罢了。
>
> > > > > > On 5/26/07, Ghost Cheng < ghost.ch...@gmail.com > wrote:
>
> > > 我是说，你等了100MS之后再处理1个客户端的数据，和等了100MS后，再处理1000个客户端的数据是不一样的。
> > > > > > > 服务器上每1MS都是很重要的，不应该把时间浪费在这里。
>
> > > > > > > On 5/26/07, qiaojie < qiao...@gmail.com> wrote:
> > > > > > > > 1000个客户端也是延迟100ms，这个跟客户端数量没有关系的。
>
> > > > > > > > 在07-5-25，Ghost Cheng < ghost.ch...@gmail.com> 写道：
> > > > > > > > > 100ms对于一般的mmo来说是足够的，对于单个客户端来说，当然是够的，
> > > > > > > > > 但是对于超过1000，2000，甚至更多的客户端来说呢？
>
> > > > > > > > > 另外，征途的流量确实比其他的游戏要大一些。
>
> > > > > > > > > On 5/25/07, qiaojie < qiao...@gmail.com > wrote:
>
> > > 这6～10ms是纯select消耗的时间，至于recv，memcpy，不管你用什么IO模型都是要做的，这部分开销是一样的。
> > 每隔100ms进行轮询的话一个请求来回的最大延迟是0.2秒，- 隐藏被引用文字 -
>
> - 显示引用的文字 -
sunway
以我们没有必要自己缓冲数据，对于MMO 来说实时性非常重要就更没有理由自己缓冲数据，除非是特定的需求需要延迟发送数据。不过这个应该是业务逻辑自
己来解决。
TCP底层来实现延迟发送应该比我们应用程序来做效率更高。所以我感觉没有必要自己缓冲数据。
我做过的TCP服务器都没有缓冲数据延迟发送，都是有数据就发。
On 5月26日, 下午1时50分, qiaojie <qiao...@gmail.com> wrote:
> 呵呵，看来你是完全听不进我的观点了，不过我到是建议你修改一下你那个征途的网关服务器，不立刻发送消息到后端，先缓存一段时间再一起发送，同时向用户发送消息 时也不要马上发送，先缓存在自己的buffer里，一段时间后再一起发送，看看这样有没有性能上的提升。...
>
> 阅读更多
>
>
>
>
>
>
> > 多线程处理游戏逻辑当然是不可能的。不过最普遍的做法是，游戏逻辑由单独的服务器来完成，并不需要处理成千上万的socket连接，而真正与用户进行网络数据交 换的网关服务器，并不需要处理游戏逻辑。N个GET线程的recv完了之后，并不一定需要将数据压到一个队列中，可以直接send到逻辑服务器。
>
> > "你在线程等待事件->处理->再等待，这个从等待到唤醒的过程难道没有系统开销吗"
> > 如果你认为这个是在浪费CPU资源，那么多线程这个概念，不要也罢。单线程"足以高效"的处理一切了。
>
> > "至于单线程恰恰浪费了很多CPU周期，我想听听你理由。"
> > 最简单的例子：按你的说法，你的主循环轮询完了之后的，如果还不到100MS，那么就sleep。
> > 那么这个时间就是被浪费的CPU周期。这时本可以利用CPU的空闲，做其他的操作，或将CPU交给另一个线程工作。
> > 人们发明了多线程编程，就是为了更好的利用，单线程处理的时候CPU被闲置的情况。
>
> > 好了，我认为这个问题继续争论下去，已经没什么意义了。注意我用的是"争论"而不是"讨论"，这已经不是讨论了，而是毫无意义的争论。
> > 既然你这么坚持的认为select比IOCP/EPOLL更高效，看起来，我除了表示一些反对意见以外，已经没有必要再争论什么了。各自按各自的想法去做吧。
>
>
> > hoho，看来你也是把我的话断章取义来理解，这样下去恐怕是要发展成意识形态之争了，好吧，我先收回我最后说的那句话。你也先不要那么激动，大家摆事实讲道理 。
>
> > >个人观点，你这是图形渲染的方面搞的太多，将显卡和网络联想到一起了，网络编程和对显卡的渲染管线编程并不一样。socket编程，你必须考虑很多的非人为的 ，不可控的突发事件。batch处理recv数据，想法也许是好的，但是如果当你的主循环idle时，socket的buffer满了怎么办？
>
> > > 首先正常情况下recv buffer不可能满，就算用户故意发送巨量请求或者因为网络阻塞把recv
> > > buffer撑满了，那也只是在客户端的send buffer里缓存，如果send
>
> > buffer也满了则客户端阻塞，你觉得这有什么问题？反倒是很好的帮你做了拥塞控制，同时也可以防止黑客攻击把服务器压垮了。事实上我通常会刻意把recv
> > > buffer设置的小一些。
>
>
> > 你在线程等待事件->处理->再等待，这个从等待到唤醒的过程难道没有系统开销吗？另外你也不可能多线程处理游戏逻辑吧？还得另外用一个队列来排队用户请求，这 不是开销吗？至于单线程恰恰浪费了很多CPU周期，我想听听你理由。
>
> > >这句话我倒是赞同的，依据以往的经验和案例，并发连接数大于1000的就已经不太适合select模型了。当然，也许你的项目，通讯量并不大，致使你的测试结 果，看起来能够让你接受。
>
> > > 在你的论述中，我看到的更多的是你根据经验的判断，如果你能拿出更多的分析和量化数据的话我想会更有说服力。
>
> > > 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
> > > > hoho～～看来微软和开源社区的一帮白痴，花了那么多精力开发出了两个更加低效的IO模型。。。嗯，佩服。
>
> > > > "有数据就处理这种模式恰恰就是低效的根源，要提高效率就应该batch处理"
>
> > 个人观点，你这是图形渲染的方面搞的太多，将显卡和网络联想到一起了，网络编程和对显卡的渲染管线编程并不一样。socket编程，你必须考虑很多的非人为的， 不可控的突发事件。batch处理recv数据，想法也许是好的，但是如果当你的主循环idle时，socket的buffer满了怎么办？
>
> > > （PS：不要认为我只是个写写服务器代码的家伙，对3D方面一无所知，在这里大放厥词，事实上我写过不止一个图形渲染引擎。）
>
> > > > "另外你要及时响应就要使用多线程，这增加了很多线程切换开销"
>
> > 难道你看到的使用IOCP/EPOLL的代码，都是开了几十上百个GET线程？通常我们使用IOCP/EPOLL时，所开的线程数量都是根据CPU数量做了优化 ，得到的结果。可以保证最大程度的合理利用CPU资源。而在这里使用单线程，恰恰浪费了很多CPU周期，这也是多线程处理的概念被发明的原因。
>
> > > > "用什么方案还是要根据具体的应用来分析"
>
> > 这句话我倒是赞同的，依据以往的经验和案例，并发连接数大于1000的就已经不太适合select模型了。当然，也许你的项目，通讯量并不大，致使你的测试结果 ，看起来能够让你接受。
>
> > > > "把采用什么IO模式当成判断系统性能的标准"， 貌似这种对我的回帖断章取义的做法更加的幼稚。
>
>
> > 当然了，我也承认select是存在着局限性，在上例中我也确实可以用epoll优化掉select轮询的开销，但是只能提高不到10％的整体性能，意义并不大 。用什么方案还是要根据具体的应用来分析，但是把iocp/epoll当成是万能药，把这做为提高性能的唯一方法，而不去分析具体应用的特性不去合理的分配系统 资源，这样做出来的系统反而更低效。把采用什么IO模式当成判断系统性能的标准，这种判断幼稚了点。
>
> > > > > 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
>
> > 总之，在针对大量并发连接的时候，IOCP/EPOLL模型的效率，根本不是select能够比拟的。IOCP/EPOLL，正是为了解决select各项缺点 ，才被发明出来的。
> > > > > > select这种模型，在处理成千上万的并发连接时，不能做到最快速的响应。
>
>
> > 你在处理1000个连接的时候，也许你觉得select可以满足你的要求，但是当你的业务逻辑开始增长，并发连接数开始增加的时候，负载也会成几何级的增长。那 你的用户数量更多的时候，你会发现select是多么让人郁闷的模型。几十年前的技术是用来满足当时的情况的，现在时代变了，需求也变了。
>
> > PS：况且，你的测试的环境，并不是真正的1000个并发连接，每台机器200个线程发送数据，已经让第一个线程和最后一个线程工作的时间间隔很大了。个人认为 你去做那100MS的等待，无非就是将这100MS内收到的数据集中到一批处理罢了。
>
> > > > > > On 5/26/07, Ghost Cheng < ghost.ch...@gmail.com > wrote:
>
> > > 我是说，你等了100MS之后再处理1个客户端的数据，和等了100MS后，再处理1000个客户端的数据是不一样的。
> > > > > > > 服务器上每1MS都是很重要的，不应该把时间浪费在这里。
>
> > > > > > > > 1000个客户端也是延迟100ms，这个跟客户端数量没有关系的。
>
> > > > > > > > > 100ms对于一般的mmo来说是足够的，对于单个客户端来说，当然是够的，
> > > > > > > > > 但是对于超过1000，2000，甚至更多的客户端来说呢？
>
> > > > > > > > > 另外，征途的流量确实比其他的游戏要大一些。
>
>
> > > 这6～10ms是纯select消耗的时间，至于recv，memcpy，不管你用什么IO模型都是要做的，这部分开销是一样的。
>
> - 显示引用的文字 -
liam
> > > > > > > > > > On- 隐藏被引用文字 -
>
> - 显示引用的文字 -...
>
> 阅读更多
Ghost Cheng
这里可能引起了大家的理解错误，我上面这段话里所指的缓冲，是针对每个用户的，并不是象qiaojie所说的，缓冲整个select轮询里所recv到的所有数据。
qiaojie
sunway
一般的loginserver的逻辑是
用户发包,然后loginserver处理,你每次轮询全部的socket带来的开销应该更大,按照你的处理逻辑,你基本上不考虑性能.
况且情况下loginserver这种应用，不够的是后台的db,loginserver的CPU足够了.
On 5月26日, 下午8时29分, qiaojie <qiao...@gmail.com> wrote:
> Nagle算法我当然知道，再用户层缓冲自然是有道理的，目的是减少send的系统调用提高性能，至于缓存的好处我就不多说了。...
>
> 阅读更多
>
> 在07-5-26，sunway <sunhui...@gmail.com> 写道：
> > > > > > > > > On 5/26/07, qiaojie < qiao...@gmail.com> wrote:- 隐藏被引用文字 -
>
> - 显示引用的文字 -
sunway
loginserver一般只会接受用户一个包,处理完了以后给用户发送一个包,
只有一次send调用，那里来的多次调用send次数的可能???
On 5月26日, 下午8时29分, qiaojie <qiao...@gmail.com> wrote:
> Nagle算法我当然知道，再用户层缓冲自然是有道理的，目的是减少send的系统调用提高性能，至于缓存的好处我就不多说了。...
>
> 阅读更多
>
> 在07-5-26，sunway <sunhui...@gmail.com> 写道：
> > > > > > > > > On 5/26/07, qiaojie < qiao...@gmail.com> wrote:- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
sunway
我感觉网关程序,尤其是MMO的网关没有必要缓冲数据,因为实时性第一重要对
MMO来说,对于那些赛车泡泡糖类游戏游戏来说更是如此.
我所知道的很多MMO都把nagle算法关闭了,就是为了提高实时性.而且阿拍奇
好象也关闭了nagle 算法.
On 5月26日, 下午8时39分, qiaojie <qiao...@gmail.com> wrote:
> 呃～～sunway开始来瞎搅和了，我们刚才是在说网关的问题，不碍loginserver的事情。...
> > 你在处理1000个连接的时候，也许你觉得select可以满足你的要求，但是当你的业务逻辑开始增长，并发连接数开始增加的时候，负载也会成几何级的增长。那- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
"这个我赞同，现在也确实是这么做的，我会将消息缓存一下，满了64K才发送，当然有时间限制，超时后，直接发送。但是在响应socket的数据时，仍然是即时响应。"
qiaojie
呵呵，这个帖子是loginserver的设计.
我感觉网关程序,尤其是MMO的网关没有必要缓冲数据,因为实时性第一重要对
MMO来说,对于那些赛车泡泡糖类游戏游戏来说更是如此.
我所知道的很多MMO都把nagle算法关闭了, 就是为了提高实时性.而且阿拍奇
sunway
比如现在有1000个用户，你500MS检查一次全部的用户,这个过程中只有100个用户有数据，是不是多调用了900次api了,这个是不是影响了性
能了?
On 5月26日, 下午8时46分, qiaojie <qiao...@gmail.com> wrote:
> 那你可以去试试采用我说的方式把epoll改成单线程处理，以一定时间间隔处理事件，看看是不是可以提升性能。
> 当然了，单线程不能发挥多核处理的优势了，解决的方法很简单，把连接按CPU数适当分组，把这些socket分配到多个线程里处理。...
>
> 阅读更多
>
> 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：
>
>
>
>
>
> > "这个我赞同，现在也确实是这么做的，我会将消息缓存一下，满了64K才发送，当然有时间限制，超时后，直接发送。但是在响应socket的数据时，仍然是即时 响应。"
>
> > 这里可能引起了大家的理解错误，我上面这段话里所指的缓冲，是针对每个用户的，并不是象qiaojie所说的，缓冲整个select轮询里所recv到的所有数 据。
>
> > PU时间花在毫无意义的轮询上，当有数据处理时，就处理，当没有数据处理时，线程就可以idle。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
sunway
On 5月26日, 下午8时47分, qiaojie <qiao...@gmail.com> wrote:
> nagle当然应该关掉，关掉了以后自己做缓存。...
>
> 阅读更多
>
> 在07-5-26，sunway <sunhui...@gmail.com> 写道：
>
>
>
>
>
> > 呵呵，这个帖子是loginserver的设计.
> > 我感觉网关程序,尤其是MMO的网关没有必要缓冲数据,因为实时性第一重要对
> > MMO来说,对于那些赛车泡泡糖类游戏游戏来说更是如此.
> > 我所知道的很多MMO都把nagle算法关闭了,就是为了提高实时性.而且阿拍奇
> > > > > > > > > > > 在07-5-26，Ghost Cheng <ghost.ch...@gmail.com> 写道：- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
qiaojie
sunway
select来能遍历完.
2,你定时遍历多长时间遍历一次比较好了?不同应用这个时间不同的，每做一个应用都要通过多次测试找出合适的值不麻烦吗?
On 5月26日, 下午8时59分, qiaojie <qiao...@gmail.com> wrote:
> .......
> sunway你严重曲解我的意思，epool是只有数据到达才产生事件，哪里来多调用API的问题？就算你用select也是一次性select所有socke t，又不是一个个去select的。...
>
> 阅读更多
>
> 在07-5-26，sunway <sunhui...@gmail.com> 写道：
> > > > > > > > > > > 在07-5-26，Ghost Cheng- 隐藏被引用文字 -
>
> - 显示引用的文字 -
qiaojie
sunway
内核里跑的。
On 5月26日, 下午9时00分, qiaojie <qiao...@gmail.com> wrote:
> 这不是造轮子，这是优化~~~...
> > 当然了，我也承认select是存在着局限性，在上例中我也确实可以用epoll优化掉select轮询的开销，但是只能提高不到10％的整体性能，意义并不大- 隐藏被引用文字 -
>
> - 显示引用的文字 -
sunway
qiaojie是定时检查连接上来所有的socket上的I/O。
比如他一次检查1K个连接，接收到其中的100个连接的数据，如果是IOCP的话，可能Get***函数要返回100次才能收完100个连接的数据包。
因此减少了API的调用，提高了性能。
这种观点也是有一定道理的，对于并发连接数不大，但是数据量很大的情况下确实能提高性能，WIN下可以用
WSAWaitForMultipleEvents实现这种解决办法。
但是这种做法的问题有以下几点。
1，在多线程下很难做到I/O线程负载均衡。因为每组的 select 线程的负载很难保证相同。
2，并发连接非常多，但是单连接I/O比较少，性能并不好，因为每次检查只有少量的I/O发生。