今天有一哥们提出了关于再flash游戏中如何再服务器端判断某些用户是否已经掉线的问题,也因此引发了一些探讨.
首先最简单的方法应该就是再服务器端socket去判断,当然再客户端也要进行对应的超时判断处理.可TCP协议本身是不带即时状态检测的,因此可能出现延迟现象等等
讨论的结果是使用"心跳"来进行检测,定时向服务器端发送特殊信息,然后再服务器端接受并做时间判断,如果一定时间内没有接收到信息,则可认为该用户已经掉线.大致思路是这样的.
然后有到网上搜索,发现了一篇文章总结的比较全面,内容如下:
几个版本的 AS API,发现Flash的socket越来越多的问题。也许早就有人总结,不过我是个新手,也不太经常看这方面的前辈经验文章,所以遇到了问题,还是自己想了点歪招。
[color=red]1、数据蒸发。[/color]这并不是Flash本身的问题,这种结构本身就有丢失数据的可能,因为之前说过,发送动作只保证一级成功,在公网上,经过n级路由器,一条命令 随时都可能蒸发。解决方法 似乎只有给每条指令加上序号,并且每条指令都立刻反馈,服务器 和客户端两方都要检查序列,并保存一定数量的 buffer。
[color=red]
2、数据粘连。[/color]Flash动画本身是有速率的,对于一个30fps的动画,如果在1/30秒内收到多条消息,在socket的buffer中,它们就会粘连在一起。因为AS的事件触发是以flash动画的根计时器为单位的。解决方法是常见的长度标记,就是在消息头部标记长度,然后将buffer中的 数据按长度切开。但是这样偶尔会有切到最后剩下半条消息的情况发生,因为它的buffer好像是定长的。同时,在高速发送数据的测试中,也发生了发送数据的粘连,多是和心跳包粘连了。发送消息是主动触发,也就是socket.flush(),所以理论上它应该和动画速率无关,为何粘连仍在考证中。
[color=red]3、离线。[/color]TCP协议 本身是不带即时状态检测的。这意味着如果一个客户端突然死机,或者网络中断(不是主动关闭),服务器是不能马上知道的。TCP 的发送消息机制会在6秒、24秒、72秒重发,遍历栈以检查客户端连接中断有时候需要2个小时,这在游戏中是不可以接受的。解决方法就是心跳检测,一段间隔发送一个特殊包给服务器,服务器立刻反馈,同时客户端和服务器端都有一个计时器,每个间隔检查最后的心跳时间和当前时间对比,超时的就可以立刻认为断线。
[color=red]4、性能。[/color]Flash由于自身的祯特性,在高速收发短命令时候性能是相对较差的。在我的实验中,每秒300多条消息(包括解密过程),就会出现丢失了,再密集一些,socket就可能异常中断。好在一般的互动游戏中,不会有这种情况出现,如果需要瞬间接受大量命令(比如进入大厅刷新在线用户列表),可以尝试在逻辑部分将数据粘合成一个大的命令。
首先最简单的方法应该就是再服务器端socket去判断,当然再客户端也要进行对应的超时判断处理.可TCP协议本身是不带即时状态检测的,因此可能出现延迟现象等等
讨论的结果是使用"心跳"来进行检测,定时向服务器端发送特殊信息,然后再服务器端接受并做时间判断,如果一定时间内没有接收到信息,则可认为该用户已经掉线.大致思路是这样的.
然后有到网上搜索,发现了一篇文章总结的比较全面,内容如下:
几个版本的 AS API,发现Flash的socket越来越多的问题。也许早就有人总结,不过我是个新手,也不太经常看这方面的前辈经验文章,所以遇到了问题,还是自己想了点歪招。
[color=red]1、数据蒸发。[/color]这并不是Flash本身的问题,这种结构本身就有丢失数据的可能,因为之前说过,发送动作只保证一级成功,在公网上,经过n级路由器,一条命令 随时都可能蒸发。解决方法 似乎只有给每条指令加上序号,并且每条指令都立刻反馈,服务器 和客户端两方都要检查序列,并保存一定数量的 buffer。
[color=red]
2、数据粘连。[/color]Flash动画本身是有速率的,对于一个30fps的动画,如果在1/30秒内收到多条消息,在socket的buffer中,它们就会粘连在一起。因为AS的事件触发是以flash动画的根计时器为单位的。解决方法是常见的长度标记,就是在消息头部标记长度,然后将buffer中的 数据按长度切开。但是这样偶尔会有切到最后剩下半条消息的情况发生,因为它的buffer好像是定长的。同时,在高速发送数据的测试中,也发生了发送数据的粘连,多是和心跳包粘连了。发送消息是主动触发,也就是socket.flush(),所以理论上它应该和动画速率无关,为何粘连仍在考证中。
[color=red]3、离线。[/color]TCP协议 本身是不带即时状态检测的。这意味着如果一个客户端突然死机,或者网络中断(不是主动关闭),服务器是不能马上知道的。TCP 的发送消息机制会在6秒、24秒、72秒重发,遍历栈以检查客户端连接中断有时候需要2个小时,这在游戏中是不可以接受的。解决方法就是心跳检测,一段间隔发送一个特殊包给服务器,服务器立刻反馈,同时客户端和服务器端都有一个计时器,每个间隔检查最后的心跳时间和当前时间对比,超时的就可以立刻认为断线。
[color=red]4、性能。[/color]Flash由于自身的祯特性,在高速收发短命令时候性能是相对较差的。在我的实验中,每秒300多条消息(包括解密过程),就会出现丢失了,再密集一些,socket就可能异常中断。好在一般的互动游戏中,不会有这种情况出现,如果需要瞬间接受大量命令(比如进入大厅刷新在线用户列表),可以尝试在逻辑部分将数据粘合成一个大的命令。