Skynet通讯遇到的奇怪问题

问题

最近在做一个内部通讯的服务器，

用的自带的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