訊息傳遞過程:
client ---> gated ---> zoned
cs訊息結構:
[cpp] view plaincopy
01.message head
02.
05.
06.message body
07.
10.
11.message csmessage
12.
傳送資料格式：16bits len + csmessage。
gated--->zoned也有一套訊息
[cpp] view plaincopy
01.message gzmessage
02.
gated發給zoned的訊息格式： total_len + gzmessage_len + gzmessage + csmessage。
gated處理過程
client連線到gated，發的第乙個包是簽名包。
gated收到len + csmessage。
gated收到第乙個包時，解析csmessage，如果簽名通過，向zoned發start_gzmessage。
接下來收到的包，gated不作任何解析，直接**給zoned。
整個的session生命週期中，gated只做一次csmessage encoding&decoding，其他時候都是透傳。
zoned處理過程
zoned收到total_len + gzmessage_len + gzmessage + csmessage。
total_len是分tcp stream用的， gzmessage_len是給zoned解析gzmessage用的。zoned先解析出gzmessage，然後將csmessage傳給邏輯層。
上面的過程的乙個優點是，沒有大量的沒必要的protobuf的message解析。
gated用到csmessage的head資訊
有的gated須要知道csmessage head的資訊，比如要知道cmd_id，以便在gated統一地控制每個命令的發包頻率，怎麼辦？
直接的做法，解析整個csmessage包，拿到cmd_id。這個成本高了點了。改變一下方式。
[cpp] view plaincopy
01.message csmessagehead
02.
05.
06.message csmessagebody
07.
就是把訊息體分成兩部分，head和body不在乙個message裡了。
傳送的訊息格式; total_len + msg_head_len + cshead + csbody。
gated只要根據msg_head_len把cshead解析出來就可以獲取頭部資訊了。
發給zoned的格式： total_len + gzmsg_len + gzmsg + cshead_len + cshead + csbody。
gated**資料給zoned時，沒有多餘的資料解析和資料拷貝。
補充：
P2P在網遊中可行性的雜思
從高可用性高效能開始研究，到分布式計算到虛擬機器到指令碼語言，一系列的思考過程，讓我又開始思考p2p在網遊中的可行性。分布式計算試圖將所有的計算單元整合成乙個完整的單元，而p2p只試 決小世界的事情。將關聯性最大的資源和計算整合在一起。我曾經向乙個朋友提起我的想法，他很嚴肅地問我，如何解決外掛程式地...
protobuf中的omitempty欄位
一句話總結 帶有omitempty欄位的成員，如果該字段為nil 字串 空陣列等 則打包的json結果不會有這個字段。我們把proto檔案自動生成go 時會出現omitempty欄位，如下 type reply struct直接上 package main import encoding json ...
Protobuf 中的型別檢查
在使用protobuffer時，如果定義乙個訊息如下 enum my enum enum type1 1,enum type2 2 message my msg required my enum test enum 1 那麼，在protoc生成的 中，在賦值時 set test enum const...