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