問題

最近在做一個(gè)內(nèi)部通訊的服務(wù)器，
用的自帶的gateserver和socketchannel做通訊，
在使用skynet.unpack或者string.unpack("XXXX",xxxx)的時(shí)候，
偶爾會(huì)出現(xiàn)

lua JSON parser does not support UTF-16 or UTF-32

之類的問題。

調(diào)查過程

調(diào)查的時(shí)候，
發(fā)現(xiàn)出問題的時(shí)候，
信息的長度會(huì)多出2個(gè)字節(jié)出來，
所以調(diào)用 ** string.unpack** 或者 skynet.unpack的時(shí)候，
無法解出其中的字符串，
一個(gè)返回nil，
一個(gè)返回原字符串內(nèi)容，
導(dǎo)致 cjson.decode 的時(shí)候報(bào)錯(cuò)了

解決過程

這個(gè)問題糾纏了很久，
總是時(shí)有時(shí)無的出現(xiàn)，
一開始還以為是編碼問題，
因?yàn)橛?個(gè)協(xié)議特別容易出問題，
而這兩個(gè)協(xié)議查理數(shù)據(jù)庫返回?cái)?shù)據(jù)的，
查看項(xiàng)目的lua文件編碼：UTF8
查看數(shù)據(jù)庫編碼規(guī)則：utf8mb4。
調(diào)查了一下是不會(huì)有問題的。

由于是通過socketchannel的response進(jìn)行回傳參數(shù)解析的，
獲取返回結(jié)果使用的是 sock:readline()，
還以為是系統(tǒng)原因，
在S端將分隔符改為 "\r\n"，
sock:readline("\r\n")，
試驗(yàn)證明，無效。

然后今天下午突然想，
一個(gè) byte 一個(gè) byte 的來讀可好，
然后先讀了個(gè) ** >I2 ** 也就是數(shù)據(jù)長度，
長度沒有問題的話就接著往下讀，
有問題的話返回 ** 0，false**,
直到把完成的數(shù)據(jù)讀出來，
然后一個(gè)一個(gè)的打印出來。

重啟啟動(dòng)發(fā)現(xiàn)，
bug沒有了。

結(jié)果

bug沒有之后，
我發(fā)現(xiàn)一個(gè)問題，
sock 會(huì)讀出 >I2 為 *** 0 *** 的一條消息，
這個(gè)消息是會(huì)占用2個(gè)字節(jié)的，
然后，
這個(gè)消息居然會(huì)每10秒鐘觸發(fā)一次，
這個(gè)難道是 gateserver 默認(rèn)的 heartbeat來讓C端 keep alive的么，【需要進(jìn)一步調(diào)查】
而那些出錯(cuò)的 bug 是因?yàn)橥ㄟ^ readline 讀取的單條消息會(huì)在第一個(gè)10s的時(shí)候和方式的消息進(jìn)行合并，
導(dǎo)致那條出錯(cuò)的消息多出了2個(gè)字節(jié)所致。

至此，基本了解了這個(gè)bug

2018-9-22補(bǔ)：
最近看教程看到的socketchannel

轉(zhuǎn)載于:https://www.cnblogs.com/adoontheway/p/9623593.html

總結(jié)

以上是生活随笔為你收集整理的Skynet通讯遇到的奇怪问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。