我自闲庭信步,悠然自得,不亦乐乎.

                                       ------ Keep life simple
GMail/GTalk/MSN:huyi.zg@gmail.com

 

TIM中c2s的事件反应模型

为了更容易理解后面的内容,先给出登录jabber服务器的交互包。
登录的xml片断

S:是server发给client的包,C:是Client to Server

Wildfire中采用的是per requst per thread的模型(确切的说是处理一个请求,需要两个线程),这种设计的缺陷是显而易见的,但优势是易于编码。当新的物理连接建立之后,一直都有线程专门对应这个连接做业务处理,直到完成全部业务后断开连接,销毁线程。
为了让单机能服务的连接数最大,TIM中不采用per thread per request的模型,而采用的是Reactor模型(ACE中已实现,更多参阅POSA2),在尽量少的线程中应答请求,避免多线程带来的开销。
由于这个原因,在应用层必须设计一个可靠的事件分配机制,将收到的包分给适当的处理器。
我的想法是坚决杜绝业务处理过程中阻塞线程。由于Reactor的特性,业务处理过程默认是在Reactor自身运行的thread中进行,如果该线程被业务处理过程阻塞,Reactor也无法监视更多的句柄状态,系统整体性能会受到严重的影响。参照前面的xml,设想如下情况,server发出标示,希望接收到客户端的验证串,在此时阻塞等待句柄的可读状态,并试图接收数据。在正常情况下,client会立刻发送验证包给server,server接收到后继续进行其他处理。这个过程看起来很流畅。但是,如果client不发送任何数据过去,server会一直处于阻塞态,线程主控权永远也不会交还给Reactor的主循环,明显这个模型是脆弱的,我们无法防止恶意用户,即使是使用超时来防止永久阻塞,系统整体性能也会受到极大影响。

未完待续...

posted on 2006-03-03 13:40 HuYi 阅读(376) 评论(0)  编辑 收藏 引用 所属分类: Server


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(12)

随笔分类

相册

收藏夹

友情链接

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜