关于flash游戏中掉线用户判断的探讨

  今天有一哥们提出了关于再flash游戏中如何再服务器端判断某些用户是否已经掉线的问题,也因此引发了一些探讨.
  首先最简单的方法应该就是再服务器端socket去判断,当然再客户端也要进行对应的超时判断处理.可TCP协议本身是不带即时状态检测的,因此可能出现延迟现象等等
  讨论的结果是使用"心跳"来进行检测,定时向服务器端发送特殊信息,然后再服务器端接受并做时间判断,如果一定时间内没有接收到信息,则可认为该用户已经掉线.大致思路是这样的.
  然后有到网上搜索,发现了一篇文章总结的比较全面,内容如下:

几个版本的 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就可能异常中断。好在一般的互动游戏中，不会有这种情况出现，如果需要瞬间接受大量命令（比如进入大厅刷新在线用户列表），可以尝试在逻辑部分将数据粘合成一个大的命令。