整個底層通信子產品修改過很多次，因為首次使用epoll，在其中遇見了很多問題，最終設計成下面的方式：
1： 對于epoll中epollout事件的使用，因為頻繁的調用send()函數，系統會在核心模式和使用者模式之間切換太多消耗太大，是以最終啟用了定時器模式，比如以50ms為間隔，定時的周遊所有的clientplayer 去發送 outstream 裡面的資料。
2： 最開始使用玩家的id 對應每個玩家的clientplayer的，在玩家沒有進入的時候 使用玩家的賬号名； 後來增加了一個map，用玩家id去映射對應的socket,在用socket 去映射對應的clientplayer。
3: 對于epoll中的epollout事件，因為啟用的是邊緣模式，是以在連接配接剛建立的時候會觸發這個事件，但是如果在之後再想通過這個時間的觸發去發送資料就不可能了。是以盡量還是不要使用epollout事件去做發送處理。
4： 每個連接配接都有自己的緩存，當緩存慢的時候就做異常處理，将這個用戶端斷開。
5： 最先設計的時候，是做成了多程序，後來修改成了單程序多線程模式。可能疑問單程序會不會影響線上，本來場景内的玩家确實要處理走動邏輯，後來考慮到這是一個模拟經營類遊戲，玩家可能不關系走動邏輯的一緻性，是以就去掉了伺服器走動邏輯的處理，交給了用戶端處理。沒有這個壓力，伺服器壓力小很多。
6： 消息的接受和發送做在了一個線程裡，不同類型的消息的處理坐在了不同的線程裡。兩者通過上篇講到的消息隊列進行通信。
7： 所有的底層api函數包括epoll相關，socket相關都做了一封裝。