定制協(xié)議錯誤數(shù)據(jù)清理問題

深愛迷惘 更新于2016-11-07

我自定義了一套協(xié)議,采用的TCP傳輸方式,協(xié)議主要作用是判斷數(shù)據(jù)完整及有效性并進行初步處理轉(zhuǎn)換成一個對象提交到ONMESSAGE里面去處理.

現(xiàn)在有一個問題,當我在INPUT里面判斷出來BUFFER里面的數(shù)據(jù)幀頭是錯誤的,不符合我的協(xié)議規(guī)范要求,這時我需要將BUFFER清空并返回0,表示清空緩沖區(qū),不調(diào)用DECODE并等待下一幀數(shù)據(jù)的到達.

測試直接設(shè)置BUFFER=NULL無效,下一幀數(shù)據(jù)到達時會加上之前錯誤的數(shù)據(jù),如果RETURN整個數(shù)據(jù)的長度又會觸發(fā)DECODE及ONMESSAGE,這樣我需要在后面兩個回調(diào)里面再次去判斷有效性,有點浪費資源.我希望數(shù)據(jù)到DECODE就已經(jīng)是有保證的有效性的數(shù)據(jù),不知道這個有什么好的解決辦法?

 3933  3 1

3個回答

wangzhibin 2016-11-07

if(數(shù)據(jù)非法) return;

這樣直接return即可

暫無評論

深愛迷惘 2016-11-07

謝謝你的解答,我先進一步測試一下,非常感謝1

暫無評論

walkor 2016-11-07

打賞

調(diào)用$connection->consumeRecvBuffer($length)來清空接收緩沖區(qū)的數(shù)據(jù)，$length代表清空多少字節(jié)。
然后input里面return 0即可。

建議：
建議收到無效數(shù)據(jù)最好把鏈接斷開，不能容忍客戶端的數(shù)據(jù)錯誤。
將buffer清空不一定保證下一個正確的包能被解析。因為清空的數(shù)據(jù)里面可能包含了下一個正確包的包頭部分，造成下一個包解析時也出現(xiàn)錯誤，如此惡性循環(huán)，可能導致這個鏈接上發(fā)來的數(shù)據(jù)都是無法解析的。