常見cs程序自定義數據包描述
常見cs程序自定義包可分為塊型包、非塊型包，非塊型包如http協議的，用\r\n\r\n結束，我們這里重點討論塊型包，塊型包常見頭部如下：
Struct PKHEAD
{
Union
{
DWORD type;
Struct
{
WORD mtype;
WORD stype;
};
};
DWORD len;
Char buf[0];
};
內容buf部分常見組織方式莫過于定長、變長兩種。定長的很簡單，如struct item{…};作為內容部分，如果不涉及到高低序問題很好辦，涉及到序的時候轉換一下。變長部分常見組織方式有這么一些經典方法：
1、 Content1 \0 content2 \0 content3 \0 …
2、 json描述。
3、 xml描述。
方法1是效率很高的，對ansi型字符串或者utf8型字符串都沒有問題，對utf16型字符串不行。解析這類變長部分的時候特別要注意包尾部的0，或者在緩沖區外部總保證存在一個0，或者保證包內尾部總存在一個結尾0，總之最后一個string要保證有一個合法的0結束，當然可能涉及到一些數值型到string型的轉換可能會導致效率下降，1的缺點在于只有一個層次。如果將內容看作key1\0value1\0key2\0value2\0…可解決無序問題，但終歸只有一個層次，不方便表示樹形數據。
方法2的效率介于1和3之間，2由于描述很簡潔，解析也是比較快的，比1好在可以解析任意層數據，嵌套N層都無所謂，閱讀也很方便，解析的時候如果原始緩沖不釋放可讓字符串不復制直接記錄在原始緩沖中的指針，這樣可進一步提高解析效率。QQ種菜的通訊協議就是json格式的，閱讀很方便，解析效率也可以，總的效率適中。
方法3的解析效率是最低的，好在xml描述性也比較強，解析代碼也很多，跟上層應用交互的時候也比較方便，作為一個支持變長的選擇也是可行的，不過如果特別在意效率的情況下避免使用，xml的解析效率比 2低了近一個數量級，比1可能低近2個數量級。
當然自定義包還有更多格式選擇，標準協議也有很多如im 里面常見的xmpp，google的protocol buffers等，還有json的一些擴展協議，如bjson等，如果只是處理一般的網游數據可能用不上這么復雜的協議，用上面提到的定長struct+1 or 2 or 3基本可以解決所有協議需求。也見到一些朋友自定義類型信息描述格式，個人覺得或許沒有必要，特別是json如此流行的情況下再自己定義似乎有重復發明輪子的嫌疑，當然具體情況具體對待，一切以滿足需求為目標。