关于flash游戏中掉线用户判断的探讨
来源:互联网 发布:2011年火过的网络歌曲 编辑:程序博客网 时间:2024/06/16 09:11
今天有一哥们提出了关于再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就可能异常中断。好在一般的互动游戏中,不会有这种情况出现,如果需要瞬间接受大量命令(比如进入大厅刷新在线用户列表),可以尝试在逻辑部分将数据粘合成一个大的命令。
首先最简单的方法应该就是再服务器端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就可能异常中断。好在一般的互动游戏中,不会有这种情况出现,如果需要瞬间接受大量命令(比如进入大厅刷新在线用户列表),可以尝试在逻辑部分将数据粘合成一个大的命令。
- 关于flash游戏中掉线用户判断的探讨
- 关于Flash游戏的渲染
- 判断用户flash是否安装了flash以及flash的版本
- 关于草根seo网站用户回访率的相关探讨
- 关于jQuery判断元素是否存在的问题示例探讨
- 用户关于ERP的五个判断
- 关于Flash/Flex平台下的游戏开发问题
- 游戏中任务的探讨
- Flash游戏的发展
- 关于session的探讨
- 关于敏捷的探讨
- 关于敏捷的探讨
- 关于工作流的探讨
- 关于RAII的探讨
- 关于引用的探讨
- 关于排序的探讨
- 关于IOCP的探讨
- 关于“递归”的探讨
- [每天一个Linux小技巧] 查看一个命令正在处理的文件
- splitcontainer左边全屏
- POJ 2418 Hardwood Species (字典树)
- RT-N14U源码研究之——wpa_supplicant
- UBUNTU 下安装新版本的 MERCURIAL (HG)
- 关于flash游戏中掉线用户判断的探讨
- 技术之路最公平也最残酷的原因是:没有捷径,需要日积月累的积累,以及对技术持久的热情
- 解散等内容的飞鸽传书
- ural 1119 Metro
- c#多线程
- ./configure: error: the HTTP rewrite module requires the PCRE library
- 取消Wmvare自动安装centOS
- HDU 1698 Just a Hook / 线段树成段更新
- java 小理解