在進行 <<協(xié)議設計>>系列之前，先寫點零碎的知識，做些鋪墊.
Google的libprotobuf，已經(jīng)很強大了，開始接觸的時候還是2.1版本，現(xiàn)在已經(jīng)到了2.2了，新版最大的變化就是添加了libprotobuf-lite！，是libprotobuf的精簡版，更加的輕量級，非常適合我的口味。
我比較推崇這個數(shù)據(jù)交換引擎，平時也在自己的代碼里面有過應用，比如做簡單的IM，文件傳輸?shù)龋紭O為方便，看重的幾點好處如下（手冊中描述的好處就省了）：
1.提供接口描述語言(IDL),無論是做客戶端，還是做服務端，都在面向接口編程。而且IDL語法規(guī)則很簡單，和C的結構體語法類似。
2.自動生成序列化及反序列化代碼，讓開發(fā)人員脫離了協(xié)議的細節(jié)，把更多的精力放到業(yè)務邏輯的編寫上
聽起來不錯，事實上也真不錯，不過還有幾個問題需要考慮：
1.你的客戶端能帶上libprotobuf這個包嗎？
2.你的客戶端如果只支持C語言，怎么辦？比如手機客戶端
3.要讀懂libprotobuf的編碼原理，除了要有一定水平，還需要時間，其它項目成員能夠接受嗎？
我身邊有朋友就碰到一種情況：一個手游項目，客戶端是C的，服務端c++的，而且客戶端和服務端是異地開發(fā)，如果從頭做起，需要先協(xié)商好每個消息的結構，開發(fā)時這里不可避免的要涉及消息的序列化及反序列化，如果挨個消息手動解析，工作量會很大，而且調試困難，容易出錯，可見一個像libprotobuf這樣提供IDL的工具是很有必要的。
下面說一下，目前我的思路：
1.libprotobuf是肯定不能用了
2.為了便于雙方理解，要更多的采用常規(guī)協(xié)議設計方法
3.一個小巧的IDL還是需要的，只需要自動完成序列化和反序列化即可
舉個具體例子，假若有下面一個C的結構體：
struct SLogin
{
uint32 nId_;//用戶ID
string sPwd_;//密碼
uint8 nStatus_;//登陸狀態(tài)
};
這里為了說明方便，使用了std::string,可以用char數(shù)組代替，或者用<ptr,len>形式代替。那么編碼的時候，常規(guī)方式就是uint32占用4個字節(jié)，uint8占用1個字節(jié)，都容易理解，這里不要用libprotobuf的varint。
重點看一下string的編碼方式，其中string可以是ASCII字符串，也可以是二進制的數(shù)據(jù)塊。任何協(xié)議都遵循TLV結構，其中T為Type類型，L為Length長度，V為Value值，前面的uint32不用額外的TL是因為：（1）他是結構體的第一個成員，而第一個成員雙方約定是整形，確定了T，（2）uint32本身說明了長度為4個字節(jié)。同樣，由于雙方約定第二個結構體成員是string類型，所以只需要確定長度即可。那么長度字段本身是固定長度，還是變長的呢？如果長度固定，最少需要2個字節(jié)，該情況下，對于很短的字符串也是2個字節(jié)的長度，有些浪費。所以最好采取變長的長度，varint，每個字節(jié)的低7位是有效承載，最高位表示后面是否還有高字節(jié)出現(xiàn)。
另外，針對上面這樣簡單結構體，最好用python腳本寫個小代碼生成工具，自動生成序列化及反序列化的代碼，應該不難。
關于序列化，可以參考文本協(xié)議json做下對比，http://www.json.org/