Skynet通讯遇到的奇怪问题

标签：结果   天下   pac   cjson   查看   获取   sky   没有   lua   

问题

最近在做一个内部通讯的服务器，
用的自带的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

Skynet通讯遇到的奇怪问题

标签：结果   天下   pac   cjson   查看   获取   sky   没有   lua   

原文地址：https://www.cnblogs.com/adoontheway/p/9623593.html