Flash的socket在实际应用上需要注意的问题

本文作者：奶瓶先生 转自www.54np.com
几个版本的 AS API，发现Flash的socket越来越多的问题。也许早就有人总结，不过我是个新手，也不太经常看这方面的前辈经验文章，所以遇到了问题，还是自己想了点歪招。

1、数据蒸发。这并不是Flash本身的问题，这种结构本身就有丢失数据的可能，因为之前说过，发送动作只保证一级成功，在公网上，经过n级路由器，一条命令 随时都可能蒸发。解决方法 似乎只有给每条指令加上序号，并且每条指令都立刻反馈，服务器 和客户端两方都要检查序列，并保存一定数量的 buffer。

2、数据粘连。Flash动画本身是有速率的，对于一个30fps的动画，如果在1/30秒内收到多条消息，在socket的buffer中，它们就会粘连在一起。因为AS的事件触发是以flash动画的根计时器为单位的。解决方法是常见的长度标记，就是在消息头部标记长度，然后将buffer中的 数据按长度切开。但是这样偶尔会有切到最后剩下半条消息的情况发生，因为它的buffer好像是定长的。同时，在高速发送数据的测试中，也发生了发送数据的粘连，多是和心跳包粘连了。发送消息是主动触发，也就是socket.flush()，所以理论上它应该和动画速率无关，为何粘连仍在考证中。

3、离线。TCP协议 本身是不带即时状态检测的。这意味着如果一个客户端突然死机，或者网络中断（不是主动关闭），服务器是不能马上知道的。TCP 的发送消息机制会在6秒、24秒、72秒重发，遍历栈以检查客户端连接中断有时候需要2个小时，这在游戏中是不可以接受的。解决方法就是心跳检测，一段间隔发送一个特殊包给服务器，服务器立刻反馈，同时客户端和服务器端都有一个计时器，每个间隔检查最后的心跳时间和当前时间对比，超时的就可以立刻认为断线。

 

4、性能。Flash由于自身的祯特性，在高速收发短命令时候性能是相对较差的。在我的实验中，每秒300多条消息（包括解密过程），就会出现丢失了，再密集一些，socket就可能异常中断。好在一般的互动游戏中，不会有这种情况出现，如果需要瞬间接受大量命令（比如进入大厅刷新在线用户列表），可以尝试在逻辑部分将数据粘合成一个大的命令。