TIM中c2s的事件反应模型

为了更容易理解后面的内容,先给出登录jabber服务器的交互包。
TIM中c2s的事件反应模型登录的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的主循环,明显这个模型是脆弱的,我们无法防止恶意用户,即使是使用超时来防止永久阻塞,系统整体性能也会受到极大影响。

未完待续...
上一篇:紧张的学习


下一篇:ACE_TRACE无法显示消息