一直都隱隱約約的感覺TIM的網絡模型還是有點問題，但卻總說不出具體問題來。時不時就會想起這個事，今天在車上，終于恍然大悟。
也許是受wildfire和jabberd2的影響太深了（特別是wildfire），TIM中網絡和業務處理的聯系過于緊密，從套接口讀到數據流后，馬上就進入XML的PullParser分析階段，雖然之后有刻意的分離網絡操作和業務邏輯，但并不徹底。
有時候業務處理還是能夠感覺到網絡的存在，我覺得這是個不良的設計。
讓我耿耿于懷的，是Reactor的單線程特性?；蛟S在某些情況下這是它的優勢，但運用不當，就會成劣勢。現在的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上創建了新的試驗分支。
