为了更容易理解后面的内容，先给出登录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的主循环，明显这个模型是脆弱的，我们无法防止恶意用户，即使是使用超时来防止永久阻塞，系统整体性能也会受到极大影响。
未完待续...
登录的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的主循环，明显这个模型是脆弱的，我们无法防止恶意用户，即使是使用超时来防止永久阻塞，系统整体性能也会受到极大影响。
未完待续...
