Skynet通訊遇到的奇怪問題
阿新 • • 發佈：2018-09-11
完成 false 觸發 發現 res beat tro 通過 resp
然後先讀了個 ** >I2 ** 也就是數據長度，
長度沒有問題的話就接著往下讀，
有問題的話返回 ** 0，false**,
直到把完成的數據讀出來，
然後一個一個的打印出來。
問題
最近在做一個內部通訊的服務器，
用的自帶的gateserver和socketchannel做通訊，
在使用skynet.unpack或者string.unpack("XXXX",xxxx)的時候，
偶爾會出現
lua JSON parser does not support UTF-16 or UTF-32之類的問題。
調查過程
調查的時候，
發現出問題的時候，
信息的長度會多出2個字節出來，
所以調用 ** string.unpack** 或者 skynet.unpack的時候，
無法解出其中的字符串，
一個返回nil，
一個返回原字符串內容，
導致 cjson.decode
解決過程
這個問題糾纏了很久，
總是時有時無的出現，
一開始還以為是編碼問題，
因為有2個協議特別容易出問題，
而這兩個協議查理數據庫返回數據的，
查看項目的lua文件編碼：UTF8
查看數據庫編碼規則：utf8mb4。
調查了一下是不會有問題的。
由於是通過socketchannel的response進行回傳參數解析的，
獲取返回結果使用的是 sock:readline()，
還以為是系統原因，
在S端將分隔符改為 "\r\n"，
sock:readline("\r\n")，
試驗證明，無效。
然後今天下午突然想，
一個 byte 一個 byte
然後先讀了個 ** >I2 ** 也就是數據長度，
長度沒有問題的話就接著往下讀，
有問題的話返回 ** 0，false**,
直到把完成的數據讀出來，
然後一個一個的打印出來。
重啟啟動發現，
bug沒有了。
結果
bug沒有之後，
我發現一個問題，
sock 會讀出 >I2 為 *** 0 *** 的一條消息，
這個消息是會占用2個字節的，
然後，
這個消息居然會每10秒鐘觸發一次，
這個難道是 gateserver 默認的 heartbeat來讓C端 keep alive的麽，【需要進一步調查】
而那些出錯的 bug 是因為通過 readline 讀取的單條消息會在第一個10s的時候和方式的消息進行合並，
至此，基本了解了這個bug
Skynet通訊遇到的奇怪問題