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