在網(wǎng)絡(luò)程序的開發(fā)中，免不了會涉及到服務(wù)器與客戶端之間的協(xié)議交互，由于客戶端與服務(wù)器端的平臺的差異性（有可能是windows，android，linux等等），以及網(wǎng)絡(luò)字節(jié)序等問題，通信包一般會做序列化與反序列化的處理，也就是通常說的打包解包工作。google的protobuf是一個(gè)很棒的東西，它不僅提供了多平臺的支持，而且直接支持從配置文件生成代碼。但是這么強(qiáng)大的功能，意味著它的代碼量以及編譯生成的庫文件等等都不會小，如果相對于手機(jī)游戲一兩M的安裝包來說，這個(gè)顯然有點(diǎn)太重量級了（ps：查了一下protobuf2.4.1的jar的包大小有400k左右），而且在手機(jī)游戲客戶端與服務(wù)器的交互過程中，很多時(shí)候基本的打包解包功能就足夠了。

今天經(jīng)同事推薦，查閱了一下msgpack相關(guān)的資料。msgpack提供快速的打包解包功能，官網(wǎng)上給出的圖號稱比protobuf快4倍，可以說相當(dāng)高效了。最大的好處在與msgpack支持多語言，服務(wù)器端可以用C++，android客戶端可以用java，能滿足實(shí)際需求。

在實(shí)際安裝msgpack的過程中，碰到了一點(diǎn)小問題，因?yàn)殚_發(fā)機(jī)器是32位機(jī)器，i686的，所以安裝完后跑一個(gè)簡單的sample時(shí)，c++編譯報(bào)錯(cuò)，錯(cuò)誤的表現(xiàn)為鏈接時(shí)報(bào)錯(cuò)：undefined reference to `__sync_sub_and_fetch_4'，后來參考了下面的博客，在configure時(shí)指定CFLAGS="-march=i686"解決，注意要make clean先。

msgpack官網(wǎng)地址：http://msgpack.org/

安裝過程中參考的博客地址：http://blog.csdn.net/xiarendeniao/article/details/6801338



====================================================================================

====================================================================================

補(bǔ)上近期簡單的測試結(jié)果

測試機(jī)器，cpu 4核 Dual-Core AMD Opteron(tm) Processor 2212，單核2GHz，1024KB cache, 內(nèi)存4G。


1. 簡單包測試

  1. struct ProtoHead  
  2. {  
  3.     uint16_t uCmd;      // 命令字  
  4.     uint16_t uBodyLen;  // 包體長度(打包之后的字符串長度)  
  5.     uint32_t uSeq;      //消息的序列號，唯一標(biāo)識一個(gè)請求  
  6.     uint32_t uCrcVal;           // 對包體的crc32校驗(yàn)值(如果校驗(yàn)不正確，服務(wù)器會斷開連接)  
  7. };  
  8.   
  9. struct ProtoBody  
  10. {  
  11.     int num;  
  12.     std::string str;  
  13.     std::vector<uint64_t> uinlst;  
  14.     MSGPACK_DEFINE(num, str, uinlst);  
  15. };  

測試中省略了包頭本地字節(jié)序與網(wǎng)絡(luò)字節(jié)序之間的轉(zhuǎn)化，只有包體做msgpack打包處理.

vector數(shù)組中元素?cái)?shù)量為16個(gè)，每次循環(huán)做一次打包與解包，并驗(yàn)證前后數(shù)據(jù)是否一致，得到的測試結(jié)果如下:

總耗時(shí)(s)

循環(huán)次數(shù)

平均每次耗時(shí)(ms)

0.004691

100

0.04691

0.044219

1000

0.044219

0.435725

10000

0.043573

4.473818

100000

0.044738

總結(jié)：基本每次耗時(shí)0.045ms左右，每秒可以打包解包22k次，速度很理想。


2. 復(fù)雜包測試(vector嵌套)

  1. struct test_node  
  2. {  
  3.     std::string str;  
  4.     std::vector<uint32_t> idlst;  
  5.   
  6.     test_node()  
  7.     {  
  8.         str = "it's a test node";  
  9.   
  10.         for (int i = 0; i++; i < 10)  
  11.         {  
  12.             idlst.push_back(i);  
  13.         }  
  14.     }  
  15.   
  16.     bool operator == (const test_node& node) const  
  17.     {  
  18.         if (node.str != str)  
  19.         {  
  20.             return false;  
  21.         }  
  22.   
  23.         if (node.idlst.size() != idlst.size())  
  24.         {  
  25.             return false;  
  26.         }  
  27.   
  28.         for (int i = 0; i < idlst.size(); i++)  
  29.         {  
  30.             if (idlst[i] != node.idlst[i])  
  31.             {  
  32.                 return false;  
  33.             }  
  34.         }  
  35.         return true;  
  36.     }  
  37.   
  38.     MSGPACK_DEFINE(str, idlst);  
  39. };  
  40.   
  41. struct ProtoBody  
  42. {  
  43.     int num;  
  44.     std::string str;  
  45.     std::vector<uint64_t> uinlst;  
  46.     std::vector<test_node> nodelst;  
  47.   
  48.     MSGPACK_DEFINE(num, str, uinlst, nodelst);  
  49. };  
每個(gè)nodelst中插入16個(gè)node，每個(gè)node中的idlst插入16個(gè)id，同1中的測試方法，得到測試結(jié)果如下：

總耗時(shí)(s)

循環(huán)次數(shù)

平均每次耗時(shí)(ms)

0.025401

100

0.25401

0.248396

1000

0.248396

2.533385

10000

0.253339

25.823562

100000

0.258236

基本上每次打包解包一次要耗時(shí)0.25ms，每秒估算可以做4k次打包解包，速度還是不錯(cuò)的。


3. 加上crc校驗(yàn)

如果每個(gè)循環(huán)中，打包過程加上crc的計(jì)算，解包過程中加上crc校驗(yàn)，得到測試結(jié)果如下：

總耗時(shí)(s)

循環(huán)次數(shù)

平均每次耗時(shí)(ms)

0.025900

100

0.25900

0.260424

1000

0.260424

2.649585

10000

0.264959

26.855452

100000

0.268555

基本上每次打包解包耗時(shí)0.26ms左右，與沒有crc差別不大；