一直都隐隐约约的感觉TIM的网络模型还是有点问题，但却总说不出具体问题来。时不时就会想起这个事，今天在车上，终于恍然大悟。
也许是受wildfire和jabberd2的影响太深了（特别是wildfire），TIM中网络和业务处理的联系过于紧密，从套接口读到数据流后，马上就进入XML的PullParser分析阶段，虽然之后有刻意的分离网络操作和业务逻辑，但并不彻底。
有时候业务处理还是能够感觉到网络的存在，我觉得这是个不良的设计。
让我耿耿于怀的，是Reactor的单线程特性。或许在某些情况下这是它的优势，但运用不当，就会成劣势。现在的TIM把业务逻辑和网络IO都挤进了Reactor所控制的线程中，只要存在一点点的阻塞，吞吐率将大打折扣。
wildfire敢把网络和业务绑得那么紧，是因为它采用的per-request，per-thread的模型，网络IO引起的阻塞不会影响到其他request处理。我也没有wildfire那么大的胆子采用per-request，per-thread，上下文切换的消耗不说，毕竟线程的数量也是有限制的，我很怀疑到底能承受多少连接数，如果没有记错，Linux没有重编译内核，一个进程内最多是1024个线程，Windows能多些，好像是65535，数据可能不准确，但也说明了线程资源是有限的。同时，WFMOReactor在Windows下每个线程内可同时监视的句柄数（62个），也似乎太少了，这点也让我烦恼。
仔细推敲后，我认为还是把网络和业务完全脱离比较好一点，用至少一个线程专门操作套接口，突破WaitForMultipleObjects的句柄数限制，再用另外一个线程来完成业务。在业务线程上使用管道过滤器模式来一步一步的处理数据。当Reactor线程接收到数据后，放进MessageBlock里面，用Task框架来处理。
这种模型确实解决了原先的诸多毛病，但如果在这个时候改网络模型，对整个项目是个不小的冲击，极有可能导致在计划的时间内不能完成项目。犹豫了一下，为了保证品质，最终还是在SubVersion上创建了新的试验分支。
