一個多人在線的棋牌類網絡游戲的項目臨近尾聲，我參與了該項目的整個設計流程，並且完成了90%的核心代碼。關於這個項目，有很多地方值得聊一聊。本系列不打算把這個項目將得多麼詳細規范，那是設計文檔應該描述的，我打算只說說一些值得注意的地方。
這個項目的一個特別之處是，客戶端是手機，用戶通過移動網絡與服務器通信。和PC相比，手機的處理能力極弱，而且網絡流量費用昂貴。因為除了要考慮普通網絡游戲的一些問題之外，這兩點也需要在設計中充分考慮。
首先是開發語言的選擇，由於服務器是Linux的環境，MS的技術直接排除，至於MONO嘛，我實在不放心。可供選擇的是C++和Java，Java勝在網絡能力強大，開發周期短，有眾多框架和開源庫的支持，要寫出爛得不可接受的代碼也不容易；C++則勝在速度快。綜合各方面因素，C++更容易把這個項目變成一堆代碼噩夢，我們選擇了Java。
一、網絡
網絡游戲，首先面臨的問題當然是如何進行網絡通信。首先考慮的是HTTP協議，因為所有的J2ME手機都支持這個，我們當然想盡可能的兼容用戶。而且HTTP協議封裝程度已經非常高了，不用去考慮線程、同步、狀態管理、連接池，不過HTTP協議有兩個不爽的地方：
◇ 協議無狀態，這個問題已經困擾過很多人很多次了。我曾考慮過的解決辦法是改造HTTP協議，在數據傳輸完成之後不關閉socket，但是這樣做工作量非常大，在項目周期中，基本上就是Mission impossible，不予考慮。那麼客戶也就只能通過輪詢的方式向服務器請求數據。
◇ 網絡流量過大。就這個項目來說，網絡間傳遞的只是指令，但是每次傳遞都要加上一堆毫無用處的HTTP Head，再加上客戶端需要做輪詢，這個流量對於手機來說簡直恐怖，經簡單測試，按照0.03元/K的GPRS網絡費用計算，一局牌居然要消耗1元多的費用（每秒輪詢），實在不可接受。也許我們可以采用流量費包月的資費方式，不過這個話題與技術無關。
以上問題導致我們選擇了Socket，這意味著我們將沒有一個web環境，很多東西都要靠自己去實現：線程管理、客戶狀態監控、對象池、控制台……….
網絡部分打算采用Java NIO來實現，這是一種新的網絡監聽方式，基於事件的異步通信，可以提高性能。每個客戶端連接之後，會有一個獨立的SocketChannel與它通信，這個SocketChannel會在用戶的整個生存周期中存在。用戶如果斷開連接，服務器會得到-1，並且會拋出Connection reset異常，通過捕獲這兩個特征，可以在用戶意外斷開連接後清理相關的資源。由於NIO是異步通信的，所以沒有復雜的線程管理。
