問題

最近在做一個內部通訊的服務器，
用的自帶的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的時候和方式的消息進行合并，
導致那條出錯的消息多出了2個字節所致。

至此，基本了解了這個bug

2018-9-22補：
最近看教程看到的socketchannel

轉載于:https://www.cnblogs.com/adoontheway/p/9623593.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。