昨天和人閑扯，談到了 MMORPG 客戶端的網絡消息應該基于怎樣的模型。依稀記得很早寫過我的觀點，但是 blog 上卻找不到。那么今天補上這么一篇吧。
我認為，MMO 類游戲，服務器扮演的角色是虛擬的世界，一切的狀態變化都是在游戲服務器仲裁和演化的。而客戶端的角色本質上是一個狀態呈現器，把玩家視角看到的虛擬世界的狀態，通過網絡消息呈現出來。所以、在設計客戶端的網絡消息分發框架時，應圍繞這個職責來設計。
客戶端發起的請求分兩種：一種是通知服務器，我扮演的角色狀態發生了改變，請求服務器仲裁；另一種是，我期望獲取服務器對象的最新狀態。后一種有時以服務器主動推送來解決，也可以用主動請求，兩者主要的區別在于流量控制。
其實、對于客戶端作為狀態呈現這個角色而言，請求和回應之間的關系并沒有什么緊密聯系，并不適合使用基于 RPC 的網絡模型。這個無關乎 RPC 的實現是用 callback 還是用 coroutine 。
這是因為，當服務器的狀態改變時，客戶端關心的應該是這類事情發生時，我應該如何呈現；而不是具體到某個請求發出后，收到回應我應該怎么處理。RPC 把請求和回應緊密耦合在一起，讓回應的處理流程強依賴請求時的上下文，這樣容易引起不必要的狀態管理。
比如，我看到我們公司的一個項目中曾經出過這樣的 bug ：UI 界面上點擊一個按鈕，用 callback 的形式發起了一次 RPC 調用；在回應的 callback 函數中對 UI 界面上的元素做了一系列的修改?？墒窃诨貞木W絡消息收到時， UI 界面已經關閉了，由于處于節約內存的考慮，還觸發了一些對象銷毀流程，結果因為操控不存在的對象造成了 bug 。
你可以從別的角度來看待這個 bug 。比如說應該建立一個更穩固的 UI 框架，做更嚴謹的生命期管理。但我認為，根源問題就是沒有把請求和回應解耦造成的。
我們應該這樣看待按鈕點擊事件：它只是觸發了一個事件在服務器上運行，這個事件導致了某個服務器上的對象狀態改變了，而回應包只是通知了狀態改變的結果?？蛻舳苏嬲龅氖窃鯓诱_呈現這個結果。
如果我們把客戶端處理網絡包的流程都歸納成類似的模型，統一成一個簡單的框架就很容易了。
客戶端根據收到的網絡包進行相應的處理，無論這個網絡包是服務器的推送、還是對之前客戶端發起請求的回應。在這個框架下，只關心來了一個網絡包后的類別，根據這個類別來決定要做哪類事情。處理流程是關聯在消息類別上的，而不是關聯在單個請求上的。
對于請求回應的處理，其實和推送的處理并沒有本質的不同。只是實現上略有差別。對應回應包的處理，處理流程得到的參數不僅僅是網絡包，還需要有對應的請求數據（也就是客戶端當初自己發起請求的參數）和這個事件綁定的客戶端本地對象。
通常我們會用一個 session 號來關聯回應包和請求包，在發起請求時，不僅把請求內容打包發給服務器，同時還把它記錄在本地，用 session 關聯起來；這樣在收到請求時，可以根據 session 找回當初請求的參數，以及請求的類型，這樣就可以不必讓服務器推送完整的狀態值，客戶端可以自己找到匹配的內容。
在大部分情況下，我們還需要在發起請求時，給這個 session 綁定一個本地的對象。雖然請求本身肯定有這個信息（否則服務器就不知道該請求到底操作呢什么東西），但額外的一個本地對象使用起來更方便，可以用來攜帶少量本地狀態信息。在回應抵達時，直接操作這個綁定對象寫起來更方便。
如果用 lua 來實現，看起來大致是這樣的：
send_request(obj, req_type, req_data) -- 發起一個請求，請求類型為 req type ，參數是 req data ，綁定對象為 obj 。
function net.req_type(obj, req_data, resp_data) -- 定義一個函數來處理 req_type 這種類型的消息，可以獲得發起請求時的 obj 和 req data 以及服務器的回應 resp data 。