MMORPG 客戶端的網路消息框架

昨天和人閑扯，談到了 MMORPG 客戶端的網路消息應該基於怎樣的模型。依稀記得很早寫過我的觀點，但是 blog 上卻找不到。那麼今天補上這麼一篇吧。

我認為，MMO 類遊戲，伺服器扮演的角色是虛擬的世界，一切的狀態變化都是在遊戲伺服器仲裁和演化的。而客戶端的角色本質上是一個狀態呈現器，把玩家視角看到的虛擬世界的狀態，通過網路消息呈現出來。所以、在設計客戶端的網路消息分發框架時，應圍繞這個職責來設計。

客戶端發起的請求分兩種：一種是通知伺服器，我扮演的角色狀態發生了改變，請求伺服器仲裁；另一種是，我期望獲取伺服器對象的最新狀態。后一種有時以伺服器主動推送來解決，也可以用主動請求，兩者主要的區別在於流量控制。

其實、對於客戶端作為狀態呈現這個角色而言，請求和回應之間的關係並沒有什麼緊密聯繫，並不適合使用基於 RPC 的網路模型。這個無關乎 RPC 的實現是用 callback 還是用 coroutine 。

這是因為，當伺服器的狀態改變時，客戶端關心的應該是這類事情發生時，我應該如何呈現；而不是具體到某個請求發出后，收到回應我應該怎麼處理。RPC 把請求和回應緊密耦合在一起，讓回應的處理流程強依賴請求時的上下文，這樣容易引起不必要的狀態管理。

比如，我看到我們公司的一個項目中曾經出過這樣的 bug ：UI 界面上點擊一個按鈕，用 callback 的形式發起了一次 RPC 調用；在回應的 callback 函數中對 UI 界面上的元素做了一系列的修改。可是在回應的網路消息收到時， 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 。