1 回答

TA貢獻(xiàn)1829條經(jīng)驗(yàn) 獲得超4個(gè)贊
conn.Read(int32Buf)
您需要檢查 conn.Read 的返回值并將其與您的預(yù)期進(jìn)行比較。您在代碼中假設(shè) conn.Read 將始終完全填充給定的 4 字節(jié)緩沖區(qū)。
這個(gè)假設(shè)是錯(cuò)誤的,即它實(shí)際上可能讀取更少的數(shù)據(jù)。具體來(lái)說(shuō),它可能只讀取 2 個(gè)字節(jié),在這種情況下,您最終會(huì)\x1a\x00\x00\x00
在緩沖區(qū)中得到仍然轉(zhuǎn)換為 26 的消息長(zhǎng)度。只是,消息的前 2 個(gè)字節(jié)實(shí)際上是長(zhǎng)度的最后 2 個(gè)字節(jié)不包括在最后一次閱讀中。這意味著在讀取 26 個(gè)字節(jié)后,它不會(huì)讀取完整的消息。2 個(gè)字節(jié)是 leg 并將包含在下一條消息中 - 這就是您觀察到的。
要確保讀取緩沖區(qū)的確切大小,請(qǐng)檢查 conn.Read 的返回值或使用io.ReadFull。完成此操作后,它會(huì)按預(yù)期工作(來(lái)自評(píng)論):
好的,現(xiàn)在它完美無(wú)缺
那么為什么這只發(fā)生在新連接的上下文中呢?可能是因?yàn)榱硪粋€(gè)連接導(dǎo)致的額外負(fù)載稍微改變了行為,但足夠顯著。不過(guò),這些不是從不同連接讀取的數(shù)據(jù),而是與問(wèn)題中的描述相反的當(dāng)前連接讀取的數(shù)據(jù)。這可以通過(guò)對(duì)不同的客戶端使用不同的消息來(lái)輕松檢查。
- 1 回答
- 0 關(guān)注
- 89 瀏覽
添加回答
舉報(bào)