NetHost::Recv方法使用專集（基於mdk1.10）

爲何將此方法特別弄一個專集，由於在通訊軟件領域中，數據接收一直是一個比較有複雜的事情，處理的好很差，直接影響到程序效率。 本文就是爲了介紹NetHost::Recv配合mdk這套引擎，如何方便的解決了傳統通訊軟件中在數據接收這一塊上遇到的各類瓶頸 瓶頸1：等待數據的方式 循環sleep、阻塞recv、事件觸發（例如select epoll） 他們的缺點     循環sleepcpu吃緊     阻塞recv佔用業務線程     事件觸發，不知道有多少可讀數據，若是數據不完整，讀出數據須要用戶本身維護 NetHost的解決方案     NetHost有本身的接收緩衝，mdk引擎收到數據首先放入NetHost的接收緩衝，而後觸發OnMsg。     由於底層已經在接收了，因此recv永不阻塞，數據不夠直接返回，等下次數據到達時，OnMsg會再次被觸發 瓶頸2：一個完整消息被分紅屢次到達 來1次收1次，記錄上次接收狀態，用戶本身拼包 缺點     用戶得本身維護已接收的數據，至關於一個接收緩衝，這個緩衝必須隨着鏈接的創建與斷開建立與刪除，維護代價昂貴 NetHost的解決方案     NetHost::Recv比傳統的recv方法增長一個bClearCache參數，告訴Recv接收到數據後，是否將數據從接收緩衝刪除     bClearCache爲true時，與傳統recv方法效果同樣，好比到達數據123456789     recv 2 byte 收到12     recv 2 byte 收不到12了，收到34     bClearCache爲false時，讀出數據不被刪除，下次還能夠讀到，好比仍是到達數據123456789     recv 2 byte 收到12     recv 2 byte 仍是會收到12     應用舉例     好比好比報文格式：2byte內容長度+報文內容     到達數據0x00 0xff 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39     實際就是257byte的報文，報文內容255byte，實際達到「123456789」9byte     按照傳統作法       1.Recv(msg, 2);0x00 0xff被讀出       2.解析msg獲得內容長度，假設爲255       3.Recv(msg, 255);返回長度不夠，123456789被讀出       這時，直接return吧，數據就丟失了，用戶得創建緩衝     NetHost::Recv的作法       1.Recv(msg, 2, false);0x00 0xff被讀出,可是不從緩衝刪除       2.解析msg獲得內容長度，假設爲255       3.Recv(msg, 257);報文長度2+255，返回長度不夠，1個byte都不讀取，0x00 0xff "123456789"依舊在緩衝中       用戶能夠直接return，等待下次OnMsg觸發時再嘗試讀取       等到數據所有到達時第3.步驟就直接所有讀出來，並從緩衝刪除了，1次解決       用戶不須要sleep,不須要阻塞，不須要維護緩衝 就是這樣，有什麼問題歡迎聯繫我