skynet fly在telegram平台下出现解包错误

[merlinlqy]

Hihi，
我们使用了你的skynet_fly框架开发一个简单游戏，作为小游戏上线到telegram app。
比较奇怪的是，在某些PC和IOS，Android平台下是可以运行的，但是部分在websocket握手完以后，出现了发包错误。
在尚不清楚在什么情况下，某些机器的某些平台突然就可以了，而某些机器和某些平台又突然不可以了。
可以明确的是，该机器在没有经过telegram打包情况下是可以连通的。
分析在不可运行的机器发送过来的服务器侧消息，websocket握手完，第一个包的opcode是text。而原则上我们的包都应该是binary，长度也不太对（84vs110）。

  不知道你有没有什么想法或者修改方式

[huahua132]

按你说的问题，意思是说客户端发的第一个包格式不对是么？如果是，在服务端部分，可以考虑在业务层丢弃掉格式不对的包

[huahua132]

57de7b1
我已经在这个提交中，优化了一下，丢弃掉格式不对的包，而不是解包错误立马断开连接。

建议：
我觉得你可以分析，经过telegram的包，到底出了什么问题，我觉得有2种可能性:
1.消息包可能被截获篡改
2.客户端包被篡改，消息包额外加了东西，这里要确定是在你原本的包体里加，还是只是发了额外的消息包

确定手段:
能复现的情况下，对比客户端，服务端收发消息的逐个字节码

[merlinlqy]

试了，不是这个原因。
我尝试打印数据包，也没什么头绪。text的数据包确实可以读，但是不太像那个合理的第一包
因为是经过nginx做了wss加密，让问题变得有点复杂，不过不太像nginx的原因。
我倒是感觉是cocos底层在telegram打包后，对某些平台的包由send_binnary变成send_text

[huahua132]

我觉得可以暂时先不用nginx代理，确定一下是客户端的问题还是代理的问题。
如果是客户端的问题:
能复现的情况下，双端分别在发送和接收哪逐个打印字节码进行对比。
如果发送长度和接收长度不一致，有可能是客户端包头长度编码错误，不过不排除被串改的可能性（内网测试可以排除这个）

[huahua132]

确定一下客户端编码包头长度是否用的大端编码，看你描述的情况，有可能是用了本地编码，导致有些平台用了小端编码