手遊中的短連線

手遊採用短連線，好處自然不言而喻，所謂的短連線就是隻有需要和伺服器通訊的時候才連線伺服器，通訊完畢就斷開連線，我叫MT也採用了短連線的方式

 

弊端

1.      每次傳送訊息的連線伺服器和斷開伺服器也是一筆不小的開銷

2.      不適合那些大量即時資訊的手遊

 

優點

1.      只在需要同步的時候才和伺服器連線傳送資料, 減少了伺服器的壓力

2.      網路不給力的時候也可以玩，資料傳送失敗可以手動重發，有限的資料足以保證非WIFI的網路也可以遊戲

 

短連線的流程圖

流程圖參考：流程圖/短連線流程圖.edx

 

 

短連線的訊息處理

流程圖參考：流程圖/短連線資料傳送.edx

 

注意:

1.兩個MsgQueue和客戶端伺服器訊息狀態state都是臨界區資源，主執行緒MainThread和訊息執行緒MsgThread不可同時訪問

2.傳送訊息：MainThread 向MsgQueue中push訊息，訊息執行緒從佇列中pop訊息 接收訊息和傳送訊息相反

3.我是用的是cosos2dx引擎，因為不支援多執行緒，所以訊息執行緒MsgThread中獲得的訊息一定要壓入到訊息佇列中，主執行緒MainThread從訊息佇列MsgQueue中獲取訊息進行處理，MsgThread不能涉及到任何Cocos2dx的操作，由主執行緒MainThread來更新介面

4.連線伺服器,向伺服器傳送資料和接收伺服器回饋的訊息都是在訊息執行緒MsgThread中處理，這樣主執行緒就可以播放等待動畫，不會出現連線伺服器過慢導致主執行緒卡死的情況

5.由於是短連線，規則就是：主執行緒一次只能push一個訊息，egmsgID=0x500  然後主執行緒處於等待訊息狀態，不斷的獲取判斷訊息執行緒msgThread返回的狀態state，只有收到伺服器回饋的msgID=0x500的相同ID的訊息時，才算訊息成功。其餘的像沒有網路,連線失敗，連線超時，接收超時等等錯誤狀態，需要提示玩家是否重發訊息，玩家選擇重發訊息，則在後臺重發最後一個傳送的訊息

短連線我也是剛接觸，如果有什麼錯誤的地方，歡迎大家指正，謝謝

轉自：http://blog.csdn.net/teng_ontheway/article/details/17999177